Subject: [AAA-WG]: HA can not know which ip address to use for it's security association with the FA

From: Johan Johansson <[email-masked]>
Date: Sun, 07 Apr 2002 13:44:58 +0000

Issue:          HA can not know which ip address to store keys on
Submitter name: Johan Johansson
Submitter email address: [email-masked]
Date first submitted: 04-07-2002
Reference: 
Document:       draft-mip-9
Comment type:   Technical 
Priority:	S
Section:	4.8

This is essentially a summary of the discussion regarding issue 305 (Purpose of MIP-Foreign-Agent-Host AVP). The only possible use that has surfaced was to enable the HA to know which ip address to use for it's SA with the FA. 

The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After examination of the involved documents I can not reach any other conclusion than that the protocols allow at least 3 different possible interfaces: the one that mobile ip tunneling takes place on, the one that mobile ip control traffic is sent from and the one that diameter (control) traffic is sent from.

If we as stated in section 4.8 simply copy the value of FA-Host from the Origin-Host field of the incoming AMR and then perform a DNS lookup, which in itself is unattractive, we may at best be able to choose a Diameter interface. If we assume that the CoA address in the reg request is the one to use we are choosing the tunneling interface where a raw mobile ip client would have access to the "real" ip address.

It seems that raw MobileIP doesn't handle this case deterministically either and thus probably is a source of interopability problems in MobileIP as well. That discussion will be taken with the MobileIP wg.

In any case we can solve the problem within Diameter without relying on the resolution within MobileIP by making the foreign agent include the proper ip address in the AMR to be forwarded to the home agent. We should probably also revamp the FA-Host avp to be an FA-Address AVP.

Request changes:

Change

"4.8  MIP-Foreign-Agent-Host AVP

   The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type
   DiameterIdentity and contains the identity of the foreign agent. This
   AVP is copied from the value of the Origin-Host AVP in the AMR."

to

"4.8  MIP-Foreign-Agent-Address AVP

   The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type
   IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MUST be added by the FA to all AMRs it sends and MUST be copied to the HAR sent by the AAAH."

We *could* make it optional if we could agree on a reasonable default interface. My best guess for that would be MIP tunneling interface, in which case we could go with

"4.8  MIP-Foreign-Agent-Address AVP

   The MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type
   IPAddress and contains the IP address of the foreign agent to be used in the security association between the FA and HA. This avp MAY added by the FA to AMRs it sends and if present the AAAH MUST copy it to the HAR it sends. If the  AVP is not present the HA MAY assume that the care-of-address of the mobile node should be used for its security association with the FA. If the FA requires co-located mobile nodes to register with it the MIP-Foreign-Agent-Address AVP MUST be added to all AMRs."

Of course occurence tables and ABNFs should be updated too.

j

---

From: Tony Johansson <[email-masked]>
Date: Mon, 08 Apr 2002 12:07:34 -0700

So, what do others think about this one?

Comments are really appreciated.

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Mon, 08 Apr 2002 22:34:08 -0700

Hi Johan,

> The need for this in the first place may not be obvious, but the MobileIP RFC 3220 section 3.2 simply states that the sa is indexed by the mobile entities IP address. But which ip address? After ex…

Will someone really separate the mip control traffic on one interface and the mobile ip tunneling on another? This would mean that every time the HA receives a MIP RRQ from an FA on the mip control interface to update a tunnel endpoint, the HA should not update the tunnel endpoint to this interface, instead the HA must update the mobile ip tunneling interface, which the HA has a pointer to?! Furthermore, I guess this also would mean the HA authenticates (FA-HA auth ext) one interface (the mip
control interface) and updates another interface (mip tunnel interface) every time the FA issue a MIP RRQ?

As you state above this is not obvious in RFC3220. So, I strongly suggest that people that really believe that this is needed first gets this clarified in the mobile ip wg. I would hate to see that we try to add functionality that may not really be ok according to mobile ip and RFC3220.

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Mon, 08 Apr 2002 22:53:22 -0700

Hi Johan,

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Wed, 10 Apr 2002 00:24:02 +0200

Hi Tony,

My reasoning behind my proposition was that no harm is done if it is 
sent redundantly, but potentially great harm is done if it is not sent. 
You ask if anyone will really separate control traffic and mobile ip 
tunneling. I don't know. I'd prefer to not make assumptions, but my 
favourite solution would be for the mip-wg to state that the CoA is the 
one to use. Fredrik has been taking that discussion with the mip-wg but 
since I am currently at home ill I have not had time to follow up on 
what response he has got.

There is nothing in RFC3220 as far as I can see that forbids the 
behaviour I describe. Can we at least agree that it is wrong to copy the 
Origin-Host AVP in the AMR and use it for this purpose?

j

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Tue, 9 Apr 2002 17:10:49 -0700 (PDT)

Hi Tony,

> As you state above this is not obvious in RFC3220. So, I strongly
> suggest that people that really believe that this is needed first
> gets this clarified in the mobile ip wg. I would hate to see that
> we try to add functionality that may not really be ok according to
> mobile ip and RFC3220.

RFC3220 allows registering with the FA using a co-located address (R
bit set in advertisement). This is a scenario where the COA (tunnel
endpoint) is not the address of the FA's control interface.

thanks,

Siva

---

From: Tony Johansson <[email-masked]>
Date: Tue, 09 Apr 2002 18:41:36 -0700

Hi Siva,

> endpoint) is not the address of the FA's control interface.

I'm sorry but really don't understand what you try to arguing here.

A "co-located care-of address"  is a care-of address acquired by the
mobile node as a local IP address through some external
means, which the mobile node then associates with one of it own network
interfaces. The mode of using a co-located care-of address has the
advantage that it allows a mobile node to function without a foreign
agent, for example, in networks that have not yet deployed a foreign
agent.

The R bit set in the advertisement, which you refer to above, tells the
MN that registration with a foreign agent is required even when using a
co-located care-of address.

So, why would this R-bit have anything to do with allowing a mip control
interface and a mip tunneling interface?!

/Tony

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Apr 2002 07:27:16 -0700 (PDT)

Assigned Issue #326.

---

From: Johan Johansson <[email-masked]>
Date: Wed, 10 Apr 2002 17:23:41 +0000

>interface and a mip tunneling interface?!
The FA forwards the request if you register with the FA, which means 
that the source ip address of the UDP packet sent to the HA will have 
the ip of the FA's mip control interface. The tunneling interface is of 
course the CoA, in this case the address that the MN got on the local 
network. It is unlikely that this will be the same as that of the FA's 
mip control interface.

j

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 11 Apr 2002 05:19:28 +0200

Hi Siva,

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Sivasundar Ramamurthy
>Sent: den 10 april 2002 02:11
>To: Tony Johansson
>Cc: Johan Johansson; aaa-wg
>Subject: Re: [AAA-WG]: HA can not know which ip address to use for it's
>security association with the FA
>
>
>
>
>Hi Tony,
>

But if you use co-located care of address, you will not use an SA between
the CoA and HA, since the MN is already authenticated via the MN-HA Auth.
Ext.

/Fredrik

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Fri, 12 Apr 2002 09:18:21 -0700 (PDT)

Hi Fredrick,

> the CoA and HA, since the MN is already authenticated via the MN-HA Auth.

but is'nt the purpose of the FA-HA key to authenticate the entity
that is forwarding the request, and not the COA? 

I think RFC3220 all but says that "when the MN uses a FA COA, that COA
is also used as the src address of the request forwarded to the HA".
In which case the forwarding entity = the COA. But this is not the
case when the co-located MN is registering via the FA...

Siva