Subject: [Seamoby] CARD between Routers - will CT do?

From: "James Kempf" <[email-masked]>
Date: Mon, 13 Jan 2003 13:58:00 -0800

So most of the discussion here has been about CARD between the Mobile Node and
Access Router, and that's OK since it certainly is an important topic.

However, equally important is how two Access Routers exchange information about
the access points connected to them. This could be statically configured, but
that would be very inconvenient.

I'm wondering if this might be a good application of CT? The "context" here
would be an authenticatable list of access points connected up to a particular
router.

Comments?

            jak

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

---

From: [email-masked]
Date: Mon, 13 Jan 2003 17:33:41 -0500

Hello James,
I wouldn't want to tie it up with CT for the following reason. This information
 may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process.
How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows
of an AP configuration change, lifetime expiration). 

Also, right now, contexts are MN specific. This is not MN specific context. Let me
know if I have misunderstood your comment.

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: "Paine, Richard H" <[email-masked]>
Date: Mon, 13 Jan 2003 19:29:56 -0800

What might be more important to look at is between layer 2 access points in
wireless LANs.  IEEE 802.11f has essentially developed the context transfer
protocol between access points.  It won't be long before those access points
include routers in them.  In other words, CT does the handoff and then
routes across an fixed or an autonomous wireless LAN.

Richard H. Paine
Success is getting what you want, happiness is liking what you get!
IPPhone:  206.766.5808
Phone:  425.865.4921
Cellular:  206.854.8199
Pager:  206.797.4580
Email:  [email-masked]

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, January 13, 2003 1:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

So most of the discussion here has been about CARD between the Mobile Node
and Access Router, and that's OK since it certainly is an important topic.

However, equally important is how two Access Routers exchange information
about the access points connected to them. This could be statically
configured, but that would be very inconvenient.

I'm wondering if this might be a good application of CT? The "context" here
would be an authenticatable list of access points connected up to a
particular router.

Comments?

            jak

---

From: "Paine, Richard H" <[email-masked]>
Date: Mon, 13 Jan 2003 19:29:56 -0800

Richard H. Paine

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, January 13, 2003 1:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: [email-masked]
Date: Tue, 14 Jan 2003 09:52:53 -0500

Hi James,

CAR will exchange information related to AR, such as AP information, capabilities (of APs
but also of the AR), but it might even exchange discovery related infos. Any block exchange 
protocol will do as the "bearer" of the information. The actual bearer definition is not the 
key of CT, from my point. It is the application of this kind of exchange and its necessary 
triggers. The current work is currently focussing on handover and transfer of MN context. 

Hence, we have two differentiating factors, i.e., non-handover usage of CT (which is certainly
possible and even to be supported, as you said) and AR-related information exchange. Again, in
the context of CAR, it is the application logic (when do we send what) that matters. Re-using 
the plain "bearer" protocol, i.e., a protocol that transfers my block of bits from one AR to 
another, is not the big deal then. 

Regards,

Dirk

>Sent: Monday, January 13, 2003 5:50 PM
>To: Krishnamurthi Govind (NRC/Boston); [email-masked]
>Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
>Hi Govind,
>
>>  may be needed to refreshed at times other than that during 
>handovers, which
>is when CT happens. Infact, this information is more important 
>prior to the
>handover process.
>
>I don't think there are any restraints on CT being coupled to handover
>signaling. In fact, I believe that one of the requirements is 
>that it can be
>sent at any time. I recall a very long discussion about this 
>in Pittsburg, I
>believe.
>
>> How does an AR discover any change in the AP configuration? 
>I think this
>should be stored as soft state and should be refreshed 
>min(when an AR knows
>Ideally, the APs would have a protocol built in that would 
>allow them to notify
>the routers. But of course, we are stuck here because APs are 
>not recognized as
>a network element within IETF. Only hosts (which are end 
>nodes) and routers are.
>So we are dependent on other standards organizations to do this.
>
>I suppose one could use SNMP for this purpose. I believe IEEE 
>802.11 defines an
>SNMP MIB for 802.11 access points.
>
>> Also, right now, contexts are MN specific. This is not MN 
>specific context.
>Let me
>You are referring to the feature context having within it 
>information about a
>specific MN? Yes, that is correct, so this would be a difference.
>
>            jak
>

---

From: [email-masked]
Date: Tue, 14 Jan 2003 09:52:53 -0500

Hi James,

Regards,

Dirk

---

From: [email-masked]
Date: Tue, 14 Jan 2003 12:43:31 -0500

Hi James:

One comment below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 11:39 AM
To: Eunsoo Shim; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Eunsoo,

There is no need for discovery related messages between ARs. Routers know where
they are, the routing protocol tells them. 

[Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though.

There is, of course, an issue of the
AR finding APs attached to it, but that is a different question. That would
probably benefit by some protocol, but, of course, we have this problem about
APs being invisible as far as IP is concerned.

[Hemant] Agreed, I think we can delegate this task to link layer standardization bodies.

The idea of using CT for CARD between routers came out of some discussions we've
been having here about how best to implement these protocols. Having a generic
framework within which all the inter-AR signaling can fit could make the
implementation cleaner. For example, one could view the HI/HAck signaling of
FMIP as another instance of CT.  One could imagine extending the routing
protocol to do implement the framework, but having a separate protocol might be
better.

Anyway, maybe this is boiling the ocean. We are already having enough trouble
getting the specs done on CT and CARD for MNs. Maybe we ought to finish that
first, then revisit the issue when we have more experience with implementing
these protocols.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 14, 2003 6:00 AM
Subject: Re: [Seamoby] CARD between Routers - will CT do?

> Hi, James,
>
> There should be two types of messages between ARs for CARD.
> - Discovery process related
> - Attributes (including information about access points) related
>
> And there can be two modes of attribute information exchange.
> - One time request-response
> - Periodic updates (one time request and follow-up periodic responses)
>
> I have two questions about your suggestion.
> 1) You are suggesting using CT for attribute information exchanges but not
> the discovery related signaling, aren't you?
> 2) Will CT support the above modes of attribute information exchange?
>
> My feeling is that we'd better identify the type of messages for CARD first
> and then can think about reusing any other protocol for the messages. And I
> think we need more discussion or output from the design team regarding the
> message types.
> Thanks.
>
> Eunsoo
>
> ----- Original Message -----
> From: "James Kempf" <[email-masked]>
> To: <[email-masked]>
> and
> about
> particular

---

From: [email-masked]
Date: Tue, 14 Jan 2003 15:48:20 -0500

Hi James:

See below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 3:30 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Hemant,

> [Hemant] Routing protocol does not tell physical neighborhood. It tells
logical neighborhood. So a router one hop away from me could actually be far
away physically and no candidate for handoff. Turning it around, routers
physically next to each other can be in different BGP domains and BGP aggregated
(or otherwise) exchanges do not have this information. So, I think discovery
related message are very much required and issues draft has emphasized it. How
you do it is open for discussion though.

As I mentioned at the ATL meeting, interdomain CARD is not possible unless the
ISP exposes some part of the internal routing tables to the other domain, namely
the access routers. 

The access routers are not border routers, they are internal
routers. BCP in the Internet today is to not expose such information to peering
ISPs. Are you proposing that we change this practice?

Hemant --> I  agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. 

As for your point about physical v.s. logical, my recollection of past
conversations on this was that we had concluded that it is possible to determine
whether a router is in the geographical neighborhood of another only if a) the
information is configured in b) both routers have access to some source of
geographical information about the other and can calculate the geographical
distance somehow (but that still doesn't tell whether it's possible to move from
a cell of an access point connnected up to one router to a cell connected to the
other router, i.e. wireless connectivity between routers) or c) a mobile node
which can hear both routers tells one about the other either before handoff or
afterwards (which does give wireless connectivity).

Of these three a) is of course always possible, b) is impractical and still
needs some way to determine wireless connectivity, and c) is possible using MN
to AR CARD, together with an inter-router protocol that allows the access router
to tell if the MN is telling the truth. Therefore, I'm curious where you see a
need for additional information to be exchanged about routers about wireless
connectivity, and how that could be determined?

Hemant --> I generally agree with your points a), b), c) above. The information of the kind you mention here is what I was referring to, in addition to capability exchange between ARs.

Regards,
Hemant

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 16:45:53 -0600

Govind, Jim,

I am starting from the beginning of the thread, forgive me
if this has been brought up in the following emails (I will know soon).

Capability information was brought up early on as one legitimate 
type of information that can be handled by CT.
I guess, this fell through the cracks somehow.

As Jim said, CT is not limited to "during" handovers, we are
considering pre-handover CTs as a scenario.

CT does not have to be MN specific, we can certainly design it
that way. But why is it not MN specific? Isn't capability
discovery done to find a good home for a specific MN?
If Capability discovery is just done for statistics/ network
management purpose, then it can be handled in many different
ways (including through a specialized entity).

I can understand the CARD folks not wanting to make their
protocol independent of CT signaling, but that does not
prevent people from using CT to carry capability information.

Regards,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:34 PM
To: [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 16:45:53 -0600

Govind, Jim,

Regards,

Madjid

-----Original Message-----

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 16:50:28 -0600

I have been forced to debate against using IAPP for generic context transfer
over and over again. IAPP only does Radius authentication and is not
suitable for dynamic context, it is not based on good triggers.

-----Original Message-----
From: Paine, Richard H [mailto:[email-masked]]
Sent: Monday, January 13, 2003 9:30 PM
To: 'James Kempf'; [email-masked]
Cc: DL WTWG
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Richard H. Paine

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, January 13, 2003 1:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 16:50:28 -0600

-----Original Message-----
From: Paine, Richard H [mailto:[email-masked]]
Sent: Monday, January 13, 2003 9:30 PM
To: 'James Kempf'; [email-masked]
Cc: DL WTWG
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Richard H. Paine

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, January 13, 2003 1:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 17:00:48 -0600

Jim,

I agree with you. It is not boiling the ocean. I don't intend to run
250 different protocols right before a handover. If I can get two birds
with one stone, I will.

CT can be extended to carry capability info and designing a mobility
framework, I may just use that, if I have other selection procedures.

I can understand CARD people's concern about relying on CT, but
I also never understood, why TAR selection and address translation
should be done by one and same protocol. I thought in Atlanta we were
talking about separating the two?

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 10:39 AM
To: Eunsoo Shim; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Eunsoo,

they are, the routing protocol tells them. There is, of course, an issue of the

            jak

---

From: [email-masked]
Date: Tue, 14 Jan 2003 18:07:16 -0500

Madjid,
My initial mail was because of the following reason. First, the triggers may be totally different. When I said around CT happens around handover time, as far as I remember these triggers for CT happened around handover time (I might be wrong here and I must accept its been sometime since I read the CT requirements/issues doc). If CT were
to be the bearer for CARD capability discovery it should be adapted to accept CARD triggers. Thats all I meant. This can be done, but I don't know whether this exists.

Though capability discovery is to find a good home for the MN, the capabilities in question pertain to ARs not MNs, thats what I meant by AR-specific and not MN-specific.  

Again, these are optmizations that Jim suggested. If the design team for CARD discovery comes with generic ICMP options for CARD for inter AR excahnges, 
it can be sent along with CT messaging, I don't deny it.
I guess we will have to go through the same cycle of discussions as we had with FMIPv6 and CARD interaction. 

Cheers,
Govind.

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 5:46 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]

Govind, Jim,

Regards,

Madjid

-----Original Message-----

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: [email-masked]
Date: Tue, 14 Jan 2003 18:07:16 -0500

Madjid,

Cheers,
Govind.

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 5:46 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]

Govind, Jim,

Regards,

Madjid

-----Original Message-----

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 17:24:25 -0600

Govind,

I agree, the triggers are in general case different and
I understand, you not wanting to rely on CT for your messaging.
In fact I myself am in favor of not using FMIP or CT for your CARD
protocol design to keep your hands open, but at same time, you need
to keep the users options open.
I personally will not use standalone CARD in my design (due to complexity).

All I am saying is that carrying capability was something in fact
I kept advocating in early days of CT (when CARD DT
was called micromobility :) )

I guess this is a matter of taste, I think AR-specific capability signaling
 if not for assisting handovers can be part of network management that
may be handled through specialized entities. This is especially inevitable
when you are dealing with inter-admin domain cases (just as James was talking
about different ISPs), this is a very important scenario.
You can't just expect ISPs to let ARs spill their guts
to other ISPs freely....

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 5:07 PM
To: Madjid Nakhjiri; [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Madjid,

Cheers,
Govind.

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 5:46 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]

Govind, Jim,

Regards,

Madjid

-----Original Message-----

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 14 Jan 2003 17:24:25 -0600

Govind,

Madjid

-----Original Message-----

Madjid,

Cheers,
Govind.

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 5:46 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]

Govind, Jim,

Regards,

Madjid

-----Original Message-----

Hello James,

Thanks,
Govind.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Monday, January 13, 2003 4:58 PM
To: [email-masked]
Subject: [Seamoby] CARD between Routers - will CT do?

Comments?

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:25:37 -0500

Hi James:

In event of IP-layer handoff, at some point MN needs to know IP address of router it is going to connect to. So, MN will know IP address of new AR, latest after handoff. 

I am not sure if I understood your example below.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:18 AM
To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

> Hemant --> I  agree with you that CARD should not mess with Internet routing
infrastructure. With Mobile IP, MN will know its old router and new router.
Thus, information about their geographical adjacency is already exposed to third
party. CARD should only be concerned about this information (however you
distribute it and use it) without impacting routing infrastructure in any way.
CARD is an edge phenomenon.

The MN only knows the AP identifier, it doesn't know the router.

For example, suppose I have an MN with an 802.11b card and two hotspot
providers, in different ASs, are providing service in the airport I happen to be
in: one does the United lounge and the other does the rest of the airport. If I
am standing next to the United lounge and using the provider for the rest of the
airport, my laptop may be able to see the BSSID for the United lounge but it
won't know anything about the IP routing infrastructure, unless, of course, CARD
or some other protocol tells it. Similarly, the routers in the other provider
won't know anything about the routers in the United provider.

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:30:32 -0500

Hi James:

One comment below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:24 AM
To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

> If two ISPs are not willing to disclose even the IP addresses and the MAC
> addresses of their access points and access routers to each other, well, the
> dynamic discovery mechanism won't be used for inter-domain CAR discovery.
> But they might do it for seamless roaming between the wireless networks of
> theirs as a part of the roaming agreements and there can be business
> benefits for them in doing that. So I'd suggest we look for technical
> solutions even for inter-domain CAR discovery.
> And intra-domain discovery of CARs is beneficial for the wireless ISPs
> anyway since it reduces their management overhead.
>
> So I think inter-AR signaling for dynamic discovery should be under our
> consideration.
>

How do you propose to authenticate this information? The current theory of how
intra-domain CARD authentication works, if I understand correctly, is that the
MN provides unauthenticated observations of AP identifiers that it can hear to
the AR, and the AR then uses authenticated information obtained via Radius or
perhap an inter-AR CARD protocol or static configuration about what APs are
actually connected to the network, to deduce that the MN is telling the truth
that the AP is an authorized AP (though the AR can't determine the truth of
wireless connectivity this way).

Hemant --> Yes, this will what happen at handoff time. Further, the truth of wireless connectivity can be obtained if MNs that undergo handoff before this MN upload this observation to their new ARs. The new AR of previous MN can then ask the old AR of previous MN if MN was indeed connected to old AR. 

If we admit information from other ASs, then there needs to be some kind of
inter-AS protocol for obtaining authenticated information about the internal
topology of the other AS.

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:30:32 -0500

Hi James:

One comment below:

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:24 AM
To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:33:16 -0500

Hi James:

Even in MIPv6, MN needs to interact with AR to obtain IP address, AAA purposes etc. Also, AR may need to create state for MN for say CT in event of handoff. Now if AR's IP address is revealed to MN (which is not operator owned), the information is already disclosed to external parties. So, why can't this information be provided to other routers.

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:14 AM
To: Pat Calhoun; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Pat,

I assume you're talking about MIPv4, right?

In that case, the HA sees the FA's address in the case where the MN sends the
RegRqst via the FA instead of directly to the HA. Since the FA's address is also
typically the care of address for the MN, the difference isn't all that great.
The source address on the forwarded RegRqst will be the care of address, so it
looks as if the RegRqst is coming from the MN.

In MIPv6, this isn't a problem because there is no FA.

            jak

----- Original Message -----
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, January 15, 2003 6:55 AM
Subject: RE: [Seamoby] CARD between Routers - will CT do?

> >
>
> Doesn't this fly in the face of Mobile IPvx, which requires that
> internal topological information be known outside the AS? How else would
> foreign and home agents be contacted? How is this case different?
>
> PatC
>
>

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:33:16 -0500

Hi James:

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:14 AM
To: Pat Calhoun; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Pat,

            jak

----- Original Message -----
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:56:52 -0500

James,
 I agree that authenticating ARs in other domains is 
a difficult problem. For inter-domain handovers to happen, there needs to be
 some kind of an SLA that needs to exist. Can't we tag on some information in the
SLA to authenticate routers in each other's domain?

-Govind.
-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:24 AM
To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 11:56:52 -0500

James,

-Govind.
-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 11:24 AM
To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 17:22:21 -0500

Hi Eunsoo:

See below.

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

I certainly agree that the inter-provider CARD should be more tricky than
the intra-provider CARD case.
BTW, the example given by Hemant is the following in my understanding.

"The MN hands over from an AR of an ISP to an AR of another ISP
(inter-provider handoff).
Then the MN can remember the IP address of the previous AR ( AR of the
previous ISP) and inform it to the new AR (AR of the new ISP to which the MN
is currently attached). So regardless of the willingness of the ISPs, the MN
can distribute the IP addresses and L2 IDs of the ARs of one ISP to another
ISP."

Hemant --> I agree.

Now the question is how the AR can verify the information delivered by the
MN, in particular, about the ARs of a different ISP.
That is the key security problem we have to tackle. 

Hemant --> If ARs in two ISP domains have to co-operate, we may require some kind of handoff SLA between them. If that is given, then it is reasonable to assume that ARs in two ISP domains can establish SA between them. If ARs could establish SA between them (either because of same domain ownership or because of handoff SLA), one security measure could be that new AR  asks old AR if MN was indeed attached to it in a reasonable past (say 1 s). If old AR says yes, new AR and old AR conclude that they are physical neighbors exchange IP address to L2 ID mapping info and continue to exchange capability info. The subsequent MNs handing off between them get seamless handoff experience.

And this is the question
James asked me, I think.

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.

     Hemant 

In the case the two ISPs are cooperative, the problem becomes similar to
that of the intra-provider CARD.

If not, well, then, each ISP should decide what to do.
Since the IP address and the L2 IDs can be disclosed anyway, I think, the
ISPs can get more benefits by cooperating with each other to verify the
information delivered by the MN. So I'd suggest we work on the protocol
design assuming/requiring the cooperation first.

Eunsoo

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

> The MN only knows the other router after it has a link connection with the
other
> ISP. And that typically requires the MN to negotiate an authentication
exchange
> with the other ISP's NAS.
>
> In the example, the MN can hear the other ISP's AP layer 2 id, but,
because it
> hasn't negotiated an authentication exchange, it cannot discover the
address of
> the router.
>
> The router in the current ISP's network doesn't learn the other ISP's
router at
> all.
>
> Anyway, I'm not saying necessarily that the topic of interprovider CARD
should
> not be examined at some point, I just think that the problem is harder
than
> intraprovider CARD, and so probably ought to wait.
>
>             jak
>
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 15, 2003 8:25 AM
> > In event of IP-layer handoff, at some point MN needs to know IP address
of
> router it is going to connect to. So, MN will know IP address of new AR,
latest
> after handoff.
> > Thus, information about their geographical adjacency is already exposed
to
> third
> > providers, in different ASs, are providing service in the airport I
happen to
> be
> > in: one does the United lounge and the other does the rest of the
airport. If
> I
> > am standing next to the United lounge and using the provider for the
rest of
> the
> > won't know anything about the IP routing infrastructure, unless, of
course,
> CARD

---

From: [email-masked]
Date: Wed, 15 Jan 2003 17:42:01 -0500

Hi James:

See comments below:

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

> design assuming/requiring the cooperation first.

I don't think any interprovider transfer of topology information can assume
co-operation. There need to be the correct security mechanisms in place.

That said, I believe it might be possible to apply the intra-provider solution
to the interprovider case by simply extending the intraprovider example based
on, for example, standard AAA practice between two providers (this is just an
example, other techniques might be better).

Hemant --> Agree.

So, I think getting a secure intra-provider CARD first, then looking at the
inter-provider problem is the best course.

Hemant --> What we need is prerequisite that (i) ARs can establish SA between them, and (ii) are willing to participate in CARD. Then, distinction between intra provider CARD and inter provider CARD may not be needed. The pre-requisite is easily satisfied for intra case and can be satisfied for inter case by some means you describe above.  

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 17:42:01 -0500

Hi James:

See comments below:

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

Hemant --> Agree.

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 18:06:45 -0500

Jim,
I think this point was brought out in the last IETF too. The main criteria
to have inter-AR exchange (be it intra domain or inter domain) is the presence of
a SA between them. 
If a SA exists, then there is no difference between inter domain and intra domain. 
 You have pointed out some ways to establish an inter domain SA. Other ways using existing SLAs may be possible too. I think  all we should do is should put the establishment of SAs as the pre-requisite for any inter AR exchange. Once this SA is established then inter-AR exchange can proceed. 
What do you think?

-Govind.

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

            jak

---

From: [email-masked]
Date: Wed, 15 Jan 2003 18:06:45 -0500

Jim,

-Govind.

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

            jak

---

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 16 Jan 2003 04:24:23 +0000

Hi Daichi:

I do not think that establishment of SA between ARs should be within scope 
of CARD. We should start from pre-requisite that SA can be established 
between ARs. When ARs belong to same domain, this is simple. When they 
belong to different domain it is harder. In either case, there can be 
variety of ways to establish SAs - pre-shared key, domain specific 
certificates, AAA, credentials exchanged during SLAs or any other means. Why 
should CARD put any restriction on mechanism used to establish SA?

So, instead of

                      <--Interworking-->
                             |
         Intra-domain CARD   |       Inter-domain CARD
               protocol      |          protocol
         --------------------|------------------------------
         Intra-domain SA     |       Inter-domain SA
           mechanism         |          mechanism
        (CARD specific?)     |       (CARD specific?)

I am saying that, if possible, we should try,

                       CARD protocol
         ----------------------------------------------
                              |
         Intra-domain SA      |      Inter-domain SA
            mechanisms        |         mechanisms
        current/future best   |   (current/future best
            practices)        |          practices)

At this point, I cannot vouch for security of MN-report-based CARD approach. 
But, could you describe what kind of attacks do you think MN-report-based 
CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown 
that certain simple mechanisms can foil security attacks in MN-report-based 
CARD (To the least, if MN tells new AR arbitrary IP address as address of 
old AR, it can be detected). Also, the side effect of attacks, if any, does 
not adversely affect good MNs. But, of course, we could have missed some 
attack possibilities.

Hemant

>From: Daichi Funato <[email-masked]>
>To: [email-masked]
>CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Date: Wed, 15 Jan 2003 19:10:15 -0800
>
>Hi Hemant,
>
> > 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.
>
>What kind of security mechanisms are you assuming?
>I think we should not leave the security mechanisms out of the scope.
>
>Especially, MN-report-based CARD is vulnerable to an attacker.
>How to protect the communication is an essential part of CARD, I think.
>Actually, IEEE IAPP includes a security mechanism by itself.
>Do we neglect that part in CARD?
>
>IMHO, if CARD can provide secure keys for ARs, these can be used by CT
>and FMIP as well. This is another type of capability discovery.
>What do you think?
>
>Best regards,
>Daichi
>
>-------------------------------------------------------------
>Daichi Funato <[email-masked]>
>DoCoMo Communications Laboratories USA, Inc.
>
>Confidential Note:
>Privileged/Confidential Information may be contained in this e-mail
>and any attachment to it. Unless you are the addressee indicated in
>this e-mail, please notify immediately the sender by reply e-mail
>that you have received this in error and delete it from your system.
>You may not use, copy or deliver this e-mail or any information
>contained in this e-mail to anyone.  Thank you very much.
>-------------------------------------------------------------
>

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

---

From: [email-masked]
Date: Thu, 16 Jan 2003 09:27:48 -0500

Daichi,
In addition to what Hemant has described in his email, just one more point to
clarify things. I don't think CARD has to establish an SA. I mean, the messaging for
establishing an SA shouldn't be part of CARD. This would be re-inventing the wheel.
 I think CARD should depend on any proven mechanism to establish an SA. Once an SA is established then inter-AR exchange can happen.

Also, could you point out what you consider as security holes in the "MN-report" based 
CARD protocol? We have illustrated several security checks in our latest draft. We have
also shown how genuine MNs will never be affected, i.e. sent to the wrong AR. However,
if you still think there are some holes, please let us know and we will attempt to 
rectify that. 

Thanks,
Govind.

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 10:10 PM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Hi Hemant,

> 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 

Best regards,
Daichi

Confidential Note:

---

From: [email-masked]
Date: Thu, 16 Jan 2003 09:27:48 -0500

Daichi,

Thanks,
Govind.

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 10:10 PM
To: Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] CARD between Routers - will CT do?

Hi Hemant,

Best regards,
Daichi

Confidential Note:

---

From: [email-masked]
Date: Thu, 16 Jan 2003 12:52:42 -0500

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

---

From: [email-masked]
Date: Thu, 16 Jan 2003 12:55:44 -0500

Hi James:

One suggestion: Referring second diagram below, we could design CARD agnostic to intra or inter classification, but assuming that ARs can establish SAs. Then, we provide subsections on how this would be achieved for intra case and inter case. Of this first subsection will be ready first (as it is easier) and we continue to work on second subsection over time. What do you think?

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 12:49 PM
To: Hemant Chaskar; [email-masked]; Chaskar Hemant
(NRC/Boston)

What do you mean by an SA? An IPSec SA? If so, how do you propose to have the
routers use that for checking that the AP L2 addresses provided by the MN map
into IP addresses that are authorized to route on the service provider's
network?

Note that the IESG is requiring that the Security Considerations of all protocol
drafts describe, precisely, how the protocol will be secured. It is no longer
sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but
it must be specified precisely how those protocols are used for securing the
protocol in question.

            jak

---

From: [email-masked]
Date: Thu, 16 Jan 2003 14:49:53 -0500

Jim,
comments inline.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 12:49 PM
To: Hemant Chaskar; [email-masked]; Chaskar Hemant
(NRC/Boston)

What do you mean by an SA? An IPSec SA? 
---> By SA, I mean a trust relationship. It can be using an IPSec SA or 
any other means. They have enough information to authenticate each other.

If so, how do you propose to have the
routers use that for checking that the AP L2 addresses provided by the MN map
into IP addresses that are authorized to route on the service provider's
network?

----> We have illustrated one method to do this in our draft.

-----> OK. 

            jak

---

From: [email-masked]
Date: Thu, 16 Jan 2003 14:49:53 -0500

Jim,
comments inline.

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 12:49 PM
To: Hemant Chaskar; [email-masked]; Chaskar Hemant
(NRC/Boston)

-----> OK. 

            jak

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Jan 2003 16:00:32 -0500

Inter-domain CARD:

Let me see if I understand this correctly: to perform an inter-system
handover based upon CARD, I would need a service agreement between
the two operators, CARD at each AR, CARD at the MN, a path and a protocol
for transferring information (including "topology information"?)
between ARs in two different domains *and* all the aforementioned security 
overhead.

Or, on the other hand, the two operators could agree to mutually configure
their networks so that the network controlled handover algorithms direct the
mobile to the appropriate AR in the neighbouring domain. The handover
algorithms
stay basically the same, the operators do not need to exchange topology 
information (there are other, easier methods for finding out where the
access 
points are mounted, if that was the intent). But no discovery protocol, no
AR to AR signalling and no SA required between ARs (other then, perhaps CT, 
if you believe in CT for seamlessness).

Lot's of L2 issues, but they exist in either scenario.

Gary

> Sent: January 16, 2003 14:50
> To: [email-masked]; [email-masked];
> [email-masked]
> > CARD is vulnerable to? In 
> draft-trossen-seamoby-dycard-00.txt, we have shown

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 16 Jan 2003 16:00:32 -0500

Inter-domain CARD:

Gary

---

From: [email-masked]
Date: Fri, 17 Jan 2003 09:50:51 -0500

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked]; [email-masked]; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD: 

[Hemant] There isn't need to transfer topology information. We should call it rev. adr. translation info which is IP addresses of AR (not all routers in domain) and their AP IDs.

Or, on the other hand, the two operators could agree to mutually configure 
their networks so that the network controlled handover algorithms direct the 
mobile to the appropriate AR in the neighbouring domain. The handover algorithms 
stay basically the same, the operators do not need to exchange topology 
information (there are other, easier methods for finding out where the access 
points are mounted, if that was the intent). But no discovery protocol, no 
AR to AR signalling and no SA required between ARs (other then, perhaps CT, 
if you believe in CT for seamlessness).  

[Hemant] There is no consensus that network controlled handoff is the way to go. But, even for this case you need a path, protocol and security mechanisms to transfer information between domains. You could call it CARD. That is of course, you are not suggesting to keep static information exchanged at the time SLA was struck and manually refresh it whenever something changes in a network domain. 

Gary 

> [ mailto:[email-masked]] 
> From: ext James Kempf [ mailto:[email-masked]]

---

From: [email-masked]
Date: Fri, 17 Jan 2003 09:50:51 -0500

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked]; [email-masked]; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD: 

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 17 Jan 2003 10:30:17 -0500

Thanks Hemant. 
 
I still don't understand the need for CARD.
 
The advantage of network controlled handover, or mobile assisted handover,
is that you don't have to transfer information across a limited resource
channel
to an entity, the MN that is clearly less trustworthy. In addition, it's
always worth
while for the MN to have less responsibilities, as this lowers complexity,
power
consumption, etc.
 
Thanks again,
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: January 17, 2003 09:51
To: Kenward, Gary [CAR:AN10:EXCH]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];
[email-masked]; Chaskar Hemant (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD: 

[Hemant] There isn't need to transfer topology information. We should call
it rev. adr. translation info which is IP addresses of AR (not all routers
in domain) and their AP IDs.

[Hemant] There is no consensus that network controlled handoff is the way to
go. But, even for this case you need a path, protocol and security
mechanisms to transfer information between domains. You could call it CARD.
That is of course, you are not suggesting to keep static information
exchanged at the time SLA was struck and manually refresh it whenever
something changes in a network domain. 

Gary 

> [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: ext James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > >contained in this e-mail to anyone.  Thank you very much. 
<https://www1.ietf.org/mailman/listinfo/seamoby>  
<http://join.msn.com/?page=features/featuredemail>  
<https://www1.ietf.org/mailman/listinfo/seamoby>  
<https://www1.ietf.org/mailman/listinfo/seamoby>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 17 Jan 2003 10:30:17 -0500

Thanks Hemant. 

 
Thanks again,
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: January 17, 2003 09:51
To: Kenward, Gary [CAR:AN10:EXCH]; [email-masked];

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked];

Inter-domain CARD: 

Gary

---

From: [email-masked]
Date: Mon, 20 Jan 2003 08:49:52 -0500

Hello Eunsoo,

I also prefer one CARD protocol that works for inter-domain and intra-domain
operations.
We need to analyze security threats on CARD in details and find out security
requirements and solutions.
To discuss the security threats, first of all, we need to identify the
discovery mechanisms we want to consider.
There were two proposals before the design team was formed.
To continue discussion on security issues, I am looking for proposals on
base discovery mechanisms from the design team.
If the design team has the same proposals from the existing two proposals,
then we can start security analysis of the discovery mechanisms.
Regards,

Eunsoo

[Govind] The requirements document elaborates some of the security issues.
Do you think we would need something additional than that. How we achieve
these security targets is a different issue.

Thanks,
Govind.