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: "Eunsoo Shim" <[email-masked]>
Date: Mon, 20 Jan 2003 19:03:37 -0800

Hi,

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.

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.

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

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.

Could anybody correct me if I am wrong about the issues in the above?
Regards,

Eunsoo

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, January 17, 2003 6:44 AM
Subject: choices for rev. adr. translation mechanisms [was: CARD between
Routers - will CT do?]

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:

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

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

- 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

- 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

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 20 Jan 2003 19:03:37 -0800

Hi,

Security threat:

4) Scalability:

Eunsoo

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, January 17, 2003 6:44 AM
Subject: choices for rev. adr. translation mechanisms [was: CARD between
Routers - will CT do?]

Hi,

- Easily secured

Comments?

Hemant

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Jan 2003 10:08:04 -0800

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

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.

> dynamic discovery to avoid inflexible static configuration. I'd prefer less

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.

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

> forward the query to all of the federated domains' servers. It does not look

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

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Jan 2003 10:08:04 -0800

Doesn't matter.

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 21 Jan 2003 18:56:50 -0800

Since there are many issues, I'd suggest we discuss one by one.
My comments are inline.

> information for handover, so it can do no harm.
[eunsoo] Let's consider a dual-mode mobile terminal whose interface runs on
one mode at a time. It is like an 802.11a/b interface that can run at
802.11a or 802.11b at a time and the mobile terminal should select the
operation mode. Also consider a wireless network where multiple 802.11a and
802.11b access points are distributed.
Currently the mobile terminal is connected to a 802.11b AP and to an AR via
the 802.11b AP. Since the mobile terminal cannot receive beacons of 802.11a
APs, it is good if the current AR provides the list of CARs and the
associated APs to the mobile terminal so that the mobile terminal needs to
check accessibility to any 802.11a only when there are 802.11a APs
associated to the CARs.
The current AR can provide information of pre-discovered CARs and the
associated APs to the mobile terminal. If the current AR's CAR table
contains an entry based on the L2 address of the malicious MN, the
information is wrong and the mobile terminal may spend time and power to
scan for 802.11a APs which do not exist nearby. This is an example of a CAR
table that contains a wrong information. In general, if we cannot trust the
integrity of the CAR table generated by the discovery process, it is
difficult to develop applications using the information in the CAR table.
That's why the requirements draft says it should(must?) verify that a
claimed CAR is a real CAR.

> likely to stick around than if only 1 reports it.
[eunsoo] Keeping the information in the CAR table as soft state is a
certainly good approach for security. I think we should apply it.
However still it is preferrable to try to maintain the integrity of the CAR
table as much as possible. If we allow easy insertion of false information
into the CAR table, the CAR table won't be so useful. It may be useful just
for L2 address to IP address mapping. Even though L2 address to IP address
mapping is important for fast handoff, it is not all applications of the CAR
table.

> the MN and AR must prevent this.
[eunsoo] Yes.

Regards,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 21 Jan 2003 18:56:50 -0800

[eunsoo] Yes.

Regards,

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Jan 2003 08:53:03 -0800

> claimed CAR is a real CAR.

But this doesn't result in the MN taking any action that would result in
compromising its IP service. It is just a failure of the optimization. If there
were no CAR, the MN would have to take exactly the same action and scan. When it
scans, it will quickly find out that someone has lied to the AR and can tell the
AR, thus causing the AR to flush the bogus AP. If the AR uses an algorithm that
weighs how long it keeps an AP in the table by the number of MNs reporting the
AP, then the bogus AP will get flushed very quickly even if the MN doesn't tell
the AR that someone has lied. To maintain good quality, the AR can associate the
L2 address of the MN reporting the data with the report, then refuse to take any
reports from someone who lies. This won't work if the MN changes its L2 address
arbitrarily, of course.

I can't see any way to solve this, short of requiring a person to meticulously
record whether an AP is connected to a potential CAR or not by going around and
measuring wireless connectivity between ARs prior to anyone using the network.
Requiring this would violate one of the primary goals of CAR, to faciliate
autoconfiguration. Most of the proposals I've seen for CAR involve having the AR
infer wireless connectivity by using the AP address provided by the MN or,
alternatively, the AR address of a previous AP, then using some kind of
authenticated lookup to determine whether the AP address is a legitimate AP
connected to a legitimate AR.

Do you have any suggestions about how an AR, independently of the MN reporting
an AP or AR address, can determine whether there is wireless connectivity with
another AR without having such an extensive, hand entered database?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Jan 2003 08:53:03 -0800

jak