Subject: [Seamoby] choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?]

From: [email-masked]
Date: Fri, 17 Jan 2003 09:44:53 -0500

Hi,

Based on the discussion we had so far, DT has following choices. WG feedback on how to proceed - a) accept one approach, b) combine the two, c) reject both, d) delay the decision; would be valuable. This will prevent drastic modifications to subsequent versions of draft. I will try to summarize the premises we have:

Approach 1: Based on MN-reports about neighborhood:
----------

- Similar to draft-trossen-seamoby-dycard-00.txt (First handoff between a pair of ARs is hard handoff. This MN tells new AR where it came from, i.e., IP address of old AR. Let us call it bootstrap handoff - HO_bt) 

- No rev. adr. trans. servers required

- HO_bt cannot use fast/seamless handoff protocols, subsequent handoffs can

- If ARs verify trust relationship between them (via preferred security mechanism such as AAA, certificates, SLAs or other), could be secured from malicious MNs (new AR asks old AR if this MN was indeed connected to it within reasonable past)

- Distinction between intra and inter domain is in the method of establishing trust relationship between ARs, CARD protocol is the same for both cases
(Establishing trust relationship is easy for intra case, harder for inter case. One example of how trust relation could be established in inter case: When HA_bt tells new AR about old AR's IP address, new AR asks old AR to provide credentials, say, in the form of certificate and vice versa. If ARs are satisfied with each others' credentials, then only they go for further capability and rev. adr. translation information exchange. Other credential mechanisms are possible too. Such security mechanisms can be further studied if WG were to choose this approach)

Approach 2: Rev. adr. trans. server based approach:
-----------

(Intra-domain scope, similar to draft-funato-seamoby-gaard-01.txt)

- Network domain maintains rev. adr. trans. server that stores rev. adr. translation information of ARs in the domain

- Old AR queries rev. adr. trans. server in its domain to resolve a first L2 ID to IP address (bootstrap query - Query_bt)

- Rev. adr. trans. server replies with IP address of new AR (in the same domain) 

- Later, old and new ARs can engage in peer-to-peer capability and rev. adr. translation information exchange bypassing the rev. adr. tran. server

- Easily secured

(Extending Approach 2 to interdomain scope):

- Form federation of rev. adr. trans. servers in different domains. For this we can go for one of following approaches:

(i) rev. adr. translation servers in different domains exchange information. This is similar to IPTEL WG's Telephony Routing over IP (TRIP) Protocol (which does information exchange between ITADs (IP Telephony Admin Domains) about IP-PSTN gateways they can reach), which in turn is similar to BGP. or, 
(ii) build DNS like tree of rev. adr. trans. servers, or
(iii) require that AP ID has enough information that Query_bt can be routed over Internet to correct rev. adr. translation server, or
(iv) flood the federation of servers with Query_bt

- When going inter domain, there is no guarantee that response to Query_bt comes before handoff is imminent. So this handoff may not be able to use fast/seamless handoff protocols, subsequent handoffs can

- Security mechanism needs to be provided by server federation

Note, in any case, ISPs cannot hide rev. adr. translation information from each other. If this is intolerable, we should proceed with understanding that seamless handoff protocols SHOULD be used intra domain. This is because, these protocols will need old AR to know IP address of new AR.

Comments?

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 7:28 PM
To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Eunsoo,

The design team is still active and tasked with completing the proposal that
they started last fall.

Therefore, I think we should terminate the circular discussion we seem to be
having on this list and let them get on with their job.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 16, 2003 4:55 PM
Subject: Re: [Seamoby] CARD between Routers - will CT do?

> Please let me repeat once.
> The CARD protocol does NOT disclose the INTERNAL topology of the network
> that the MNs cannot figure out.
> Also it is not necessary for mobility management. It discloses only the AR's
> IP addresses, AP's MAC addresses and such things. Disclosing capabilities
> (attributes) can be limited by policies.
>
> So I am wondering what's the concern of the providers in exchanging the
> information that is anyway given away to the MNs.
> I am not sure that trusting another provider with any kind of cooperation
> relationship (such as roaming agreement) is more risky than trusting the
> MNs.
> Anyway this is about network provider's policies or business frameworks. I
> am not so sure we should spend lots of time on clarifying the providers'
> policies. Of course, if providers come out and provider their opinions, it
> is more than welcome.
>
> While we work on security measures for CARD, I think, we will know what's
> the requirements for inter-provider operation of CARD. I don't agree if you
> suggest we forget about inter-provider operation in designing the CARD
> protocol and create something only for intra-provider operation and then
> start looking into the inter-provider operation. For it might lead to a
> protocol that is not suitable at all for inter-provider operation in the
> beginning. I think we should keep in mind all the way that it is most
> preferable to use the same protocol for inter-provider operation as well as
> intra-provider operation. I agree to looking into intra-provider design
> first only with the intention to extend the same protocol for the
> inter-provider operation immediately rather than trying to create totally
> different two sets of protocols.
> With that in mind, we can start with a base discovery mechanism and look
> into the security measures for it. We may find that the security measures
> are very different in two cases, that is, inter-provider operation and
> intra-provider operation, or they are almost the same. Then we will be able
> to say what is the (technically) feasible approach for CARD over
> inter-provider roaming.
>
> So the most important thing for our progress is picking (a) base discovery
> mechanism(s) that we want to look into and design security measures on.
>
> How do we want to go about this? We start looking into the two individual
> proposals or any new or merged proposals from the design team? What's the
> status of the design team about it?
>
> Regards,
>
> Eunsoo
>
>
> ----- Original Message -----
> From: "James Kempf" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, January 16, 2003 10:47 AM
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> > With my service provider hat on, I'm saying that I don't think our
> operations
> > guys will approve using the IP address from another service provider's
> internal
> > topology in the fashion that you and Eunsoo are advocating. Regardless of
> > whether or not there is a Radius connection. if the MN sends it, our RAs
> will
> > simply be configured to reject it. Therefore, I think we should now try to
> > concentrate on the intra-provider case now, and deal with the
> interprovider case
> > later.
> >
> > Other service providers, want to comment?
> >
> >              jak
> >
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> > Sent: Thursday, January 16, 2003 9:52 AM
> > Subject: RE: [Seamoby] CARD between Routers - will CT do?
> >
> >
> > > Hi James:
> > >
> > > I am not sure why CARD needs to expose "internal" topology. But, to
> emphasize
> > it, we can add a guideline that
> > >
> > > (iii) CARD SHOULD/MUST not export any information between domains other
> than
> > AR addresses, Link layer IDs and capabilities.
> > >
> > > (The above information is already exposed to third parties, i.e., MNs
> > connecting to networks. So, it is not secret anymore.)
> > >
> > > Are you suggesting use of Radius to establish SAs (possible) or for
> performing
> > CARD (not sure)?
> > >
> > > Hemant
> > >
> > > -----Original Message-----
> > > From: ext James Kempf [mailto:[email-masked]]
> > > Sent: Thursday, January 16, 2003 12:22 PM
> > > To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
> > > Subject: Re: [Seamoby] CARD between Routers - will CT do?
> > >
> > >
> > > > Hemant --> I think we can start protocol design under the assumptions
> that
> > (i)
> > > old and new ARs can establish SA between them, (ii) they are willing to
> > > participate in CARD protocol. Then, there may not be any need for
> intra-domain
> > /
> > > inter-domain classification.
> > > >
> > >
> > > Alternatively, an intermediary that would be more acceptable, such as a
> Radius
> > > server, could be used. My initial point is that the two providers don't
> want
> > to
> > > expose their internal topology, even if they have an SA allowing
> > inter-provider
> > > handover.
> > >
> > >             jak
> > >
> > >
> >
> >
>
>

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

---

From: [email-masked]
Date: Tue, 21 Jan 2003 16:06:46 -0500

Hello Jim,

comments inline.

-Govind.

> I see a few problems with the rev.adr.translation server based approach.
>
> 1) The reverse address translation server can tell only that the there is a
> registered access router with the given L2 address (probably L2 address of
> the BS associated to an access router) but it cannot tell whether the access
> router is a CAR of the current AR. Now the current AR relies on the fact
> that a MN provided the L2 address matching to a registered AR. It comes with
> the following security threat.
>
> Security threat:
> A malicious MN (tampered MN) provides a L2 address which is the L2 address
> of a registered AR but not a CAR of the current AR, that is, no overlapping
> coverage with the current AR. Then the current AR will build a CAR table
> with IP addresses of ARs that are not CARs. As long as we assume a MN can be
> tampered, this attack is very easy to play since it is easy to collect the
> L2 addresses of registered access routers.
>

Doesn't matter.

At the time of handover, the MN or AR will receive from layer 2 the address of
the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP
layer 2 addresses in the CAR table with the addresses of the APs it can hear.
Thus, an AP address that is provided by a malicious MN but has no wireless
connectivity to the current AR will get filtered out when the MN or AR uses the
information for handover, so it can do no harm.

There is still the issue of the bogus AP sticking around. The AR can handle this
by making the CARD information soft state, so it times out AR layer 2 addresses
if it doesn't receive a confirmation from another MN within a certain period of
time. Thus, any bogus information only has limited lifetime, and even within
that lifetime, can't do more than occupy a table slot in the router's memory. In
fact, the AR can use the number of MNs reporting a particular address to weight
the relevence of a reported AP. So if 20 MNs report it, the AP address is more
likely to stick around than if only 1 reports it.

[Govind] This seems to be very similar to the approach taken by dycard. 

A related, but more serious, problem is if the MN undertakes a DoS attack by
flooding the AR with real or bogus layer 2 addresses. The CARD protocol between
the MN and AR must prevent this.

> 2) Another issue with the approach is that it requires static configuration.
> It is better than static configuration of CAR table at each AR but still it
> is much less flexible than something more dynamic. The motivation of CARD is
> dynamic discovery to avoid inflexible static configuration. I'd prefer less
> static configuration.
>

There could be a protocol between the server and the APs that allows them to
dynamically report this information.

The problem with having this information directly exchanged between routers is
that each router would have to keep a table of all AP/AR matches, which could be
lots of information and thus a scalability problem for the ARs.

[Govind] An AR only needs to keep information about its handover neighbors..
 not every AP/AR in the domain (considering only the intra domain case). 
So why is there a scalability issue here? OTOH, there may be scalability/availability
issues for the server for the very reason that you mention. 
 Also, if the server approach also stores the information
that it gets in a local cache, the amount of information that is stored
is the same. 

> 3) It requires a dedicated network element for CARD, that is, the reverse
> address translation server. The requirements draft says it is not allowed.
>

Right, well maybe the requirements are in error here. Why was this requirement
put in? The IESG has not approved the requirements yet, BTW.

[Govind] I agree that the IESG is still considering the draft, but the requirement 
draft has passed WG last call, therefore I don't see the reason (for sake of progress) 
why we should debate this issue now, unless ofcourse if the IESG has issues with this. 

> 4) Scalability:
> Since L2 address does not come with any domain identity typically, I am not
> sure whether the reverse address translation can work inter-domain. Whenever
> the local domain server cannot find a matching entry, it will have to
> forward the query to all of the federated domains' servers. It does not look
> scalable.
>

As Pat mentioned, the interdomain problem is out of scope.

            jak

---

From: [email-masked]
Date: Wed, 22 Jan 2003 10:19:48 -0500

Jim,

How does an AR  know what is a handover neighbor or not, independently of the MN
providing this information as part of CARD? The information provided by the MN
establishes wireless connectivity via handover between this AR's APs and another
AR's APs. The authenticated information provided by an authorized server or an
interrouter prototol provides information on what are valid AP to AR mappings
for this service provider. These are not the same, and you cannot deduce one set
of information from the other.

[Govind] If I understand you right, you are talking about the method of 
populating the cache at the AR.
There are several ways to do this. One way is explained in the dycard draft.
But the point that I was trying to get across is that an AR does not have have
 to maintain any more information that it needs for making handover decisions,
i.e. its GAAR (using an old term) information.

OK, so it would be interesting to see some scalability figures here, how does
the server based v.s. router based protocol scale? The scalability may not be
such a problem, and there may be ways of limiting the amount of information that
is propagated. From a robustness standpoint, and interrouter protocol might be
preferable, since there is no single point of failure, but I think scalability
might argue in the opposite direction.

[Govind] I don't really see a scalability problem right now with the non-server
based protocol. However, we can discuss this once the design team gets a document
out. 

            jak

---

From: [email-masked]
Date: Wed, 22 Jan 2003 10:19:48 -0500

Jim,

            jak