Subject: Re: [AAA-WG]: Issue 305: Purpose of MIP-Foreign-Agent-Host

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 16:03:25 -0800

All,

My vote is that we reject issue #305 and keep the MIP-Foreign-Agent-Host
AVP as is. After all it is only optional and it seems like some may find
it useful.

Comments / objections to this.

/Tony

Sivasundar Ramamurthy wrote:

> Hello,
>
> I might have a couple of uses for this avp.
>
> 1. The assumption here is that the FA-HA key is not session specific
> (see Issue: 317).
>
> When the HAR containing the HA-FA key is received by the HA, the HA
> needs to know which FA the FA-HA key is for. The COA in the
> reg-request must be one of the FA's addresses but need not be the
> address from which the FA forwards UDP reg requests to the HA.  The
> FQDN in FA-Host AVP might be a more reliable way to identify the FA
> and store the key against.
>
> When a UDP MIP request containing a FA-HA auth ext is received, the HA
> can get the host name of the FA from the source address (DNS) and
> determine if it has a SA to that FA. Hopefully the address the FA uses
> to forward the request matches against the hostname retrived from the
> FA-Host AVP in the HAR.
>
> NOTE: If this usage, and thus the necessity of this AVP, makes sense,
> maybe we can extend it as an argument for requiring support for the
> GNAIE drafts; the presence of a FA-host NAI in normal (UDP) reg
> requests will let the HA find a key for the FA (without using DNS) and
> authenticate it.
>
> 2. Section 1.3 in the MIP draft has text that says:
>
> "...it is necessary for the resulting HAR received by the HA to be
> identified as a continuation of an existing session".
>
> Maybe the FQDN in the FA-Host-AVP is a reliable way to determine
> session continuation??
>
> thanks!
>
> Siva

---

From: Johan Johansson <[email-masked]>
Date: Tue, 02 Apr 2002 16:53:05 +0200

But I created this issue specifically because it is mandatory in HARs 
and for some reason I can not even speculate about in HAAs. As for 
Sivasundar's use for it I have been trying to find time to think it 
through properly but not found it. I'll try to make some comments on it 
though and then Sivasundar can correct my mistakes.

The only text in the draft that touches this avp says that it is a copy 
of the Origin-Host avp of the AMR. This means that you are keying your 
SA on the diameter interface instead of the mobile ip tunneling 
interface. I am not sure if it's a good idea to use something that is 
invented by diameter to key the SA rather than something that the mobile 
ip layer of the FA sends.

A couple of weeks ago I went through the latest mobile ip draft together 
with Fredrik to see if this split between the tunneling interface and 
the control interface is supported in "raw" mobile ip. It doesn't seem 
to be explicitly disallowed at any rate, but I am still not convinced 
that it can in fact be made to work. In summary, if the FA-Host avp is 
used you can use the diameter interface to key your SA and otherwise you 
need to use the tunneling interface. Your thoughts on this Sivasundar?

Regarding detecting session continuation on the clients: I suppose the 
issue arises only for stateless clients? And for stateless clients you 
are moving the detection to the mobile ip layer, right?

j

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Tue, 2 Apr 2002 11:35:16 -0800 (PST)

> ip layer of the FA sends.

but does not the Origin-Host contain the FQDN of the FA? My
assumption is that a DNS lookup on this FQDN might give us all the
control addresses used by the FA.

> that it can in fact be made to work. 

Cant this happen when the "r" bit is set on the agent adv and the MN
is using a co-located COA? Or if the advertised COA and the
the control interface are different?

> In summary, if the FA-Host avp is 

This issue is actually related to issue #317 regarding the FA-HA key.
Based on the resolution on that, we might be able to get rid of the
need for this AVP wrt the FA-HA key.

> are moving the detection to the mobile ip layer, right?

but I was referring to the support for Handoff issues in Diameter MIP
draft section 1.3. Using the FA-Host-AVP, the HA can determine if the
MN has moved to a new realm or a different FA in the same realm. My
understanding is that the HA maintains MN session per Realm, not per
FA. But do remember that this particular usage of the AVP is a guess 
of mine.. :-)

thanks,

Siva

> >>Maybe the FQDN in the FA-Host-AVP is a reliable way to determine

Thanks,

Siva

====================================
Sivasundar Ramamurthy		
(She-va-su-ndar Ra-ma-moor-thee)

Engineer, Mobile IP Project
Hewlett Packard
(408) 447 7255
====================================

---

From: Tony Johansson <[email-masked]>
Date: Tue, 02 Apr 2002 15:00:12 -0800

I'm sorry if I was unclear in my previous mail. I meant to suggest that we
keep the MIP-Foreign-Agent-Host AVP as optional in the HAR.

What do others think?

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Wed, 03 Apr 2002 10:37:57 +0200

Fine by me. I don't have a vendetta against the FA avp. I was merely 
confused to why an avp whose use is never described was mandatory.

j

---

From: Johan Johansson <[email-masked]>
Date: Wed, 03 Apr 2002 12:29:16 +0200

>control addresses used by the FA.
Yes, it contains a DiameterIdentity that is defined to be an FQDN. First 
of all I am not sure you could get all the ip addresses using DNS, but 
assuming for the moment that you could, I guess it would work to try an 
SA-lookup on all of them and use the first that matches.

I suppose the FQDN might legally resolve to more than one ip address 
even when used as a DiameterIdentity, but there is nothing that says 
that this would include the interface(s) used for mobile ip traffic, 
control or otherwise.

>the control interface are different?
Revisiting this today we reached the conclusion that this is in fact a 
serious error either in Diameter or MobileIP. The home agent can not 
know which ip address to key the SA on. We agree that it is possible for 
an FA to send the Diameter control traffic on one interface, the 
MobileIP control traffic on a second interface and the MobilIP tunnel 
traffic on a third interface. In raw mobile ip the preshared keys are 
hopefully stored using the right ip address, but when the HA receives a 
dynamically generated key it must know which ip address to store it under.

Your example with the R bit is also a good one. You would probably be 
guaranteed that the source address in the UDP packet differs from the 
one used for the actual traffic, with the possible exclusion of when 
using NATed addresses. In any case, the HA does not know which ip 
address to use for it's SA with the FA.

Note that this means that any implementation that assumes that it knows 
how to key the SA is *severly broken*.

I can see 3 different solutions to this problem.

   1. Make the MIP-Foreign-Agent-Host avp a MIP-Foreign-Agent-Address
      avp and make it mandatory in the AMR and HAR.
   2. Since the UDP header is part of the MobileIP protocol, include the
      UDP header in the MIP-Reg-Request avp
   3. Demand that the CoA is used to key SAs in MobileIP (fat chance -
      but it is a possible solution)

>FA. But do remember that this particular usage of the AVP is a guess 
No. It cannot know if fa1.fluffybunny.nowhere.net and 
fa7.pinkelephant.nowhere.net are in the same realm or not. It only knows 
that they are different FAs. It is also my understanding that the HA 
maintains per MN sessions, not per FA or per realm. It would in other 
words be an error for a handover between two different realms to be two 
different sessions on the HA with different accounting multi session ids.

j

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Wed, 3 Apr 2002 08:45:10 -0800 (PST)

> that this would include the interface(s) used for mobile ip traffic, 

true.

>       avp and make it mandatory in the AMR and HAR.

This will work but might require the FA has to use the same
control interface to forward all reg requests to this HA. This is
needed if the HA has multiple SAs to the same FA and can expect the FA
to use any of these SAs.

>       UDP header in the MIP-Reg-Request avp

This may not work since the AAA authentication will fail for the MN,
unless the header is added after the MN-AAA auth ext (if that makes
sense at all!)

>       but it is a possible solution)

Another solution is retaining the FA-Host AVP and having the FA
include its NAI in a FA-NAI extension in the UDP request. This ext 
MUST be used if a AAA distributed FA-HA key is used. This will let the
HA key the SA on the FQDN of the FA instead of IP address.

> different sessions on the HA with different accounting multi session ids.

aah! the realm cannot be determined from the FQDN. Anyway, this
possible "usage" of the FA-Host AVP is out!

Siva

---

From: Johan Johansson <[email-masked]>
Date: Thu, 04 Apr 2002 10:05:21 +0200

Sivasundar Ramamurthy wrote:

>>In any case, the HA does not know which ip 
The interface could be changed by performing a new Diameter 
authorization and requesting a new set of keys.

>unless the header is added after the MN-AAA auth ext (if that makes
Why would it fail? Obviously, the fact that there is an UDP header 
present needs to be taken into account whenever the MIP-Reg-Request is used.

>HA key the SA on the FQDN of the FA instead of IP address.
That would prevent using aliases, so if anything you'd need to key it on 
the ip address that you get by resolving that particular FQDN. I am a 
bit confused about why you'd want to retain the FA-Host AVP while at the 
same time sending similar information at the MobileIP level? If the 
FA-Host AVP were to be retained it would most certainly have to be 
supplied by the FA itself and not taken from the Origin-Host avp of the 
AMR. But if what you will eventually need is an IP address why not send 
an IP address?

Further investigation by Fredrik in the MobileIP RFC reveals that it is 
undefined which IP address to use when looking up SAs. It is defined for 
the SA between MN and HA, but *not* for FA and HA. It simply says that 
it must be an IP address. This is of course a source of interopability 
problems that needs to be dealt with. Our local Mobile IP guy exclaimed 
with surprise for instance "It's not the CoA?"

j

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Thu, 4 Apr 2002 09:11:30 -0800 (PST)

> authorization and requesting a new set of keys.

So the FA and HA will maintain the both endpoints of the FA-HA SA as
IP addresses, not as FQDNs -- something like "This key is only
between this address of mine to this address (of some FA)".

> present needs to be taken into account whenever the MIP-Reg-Request is used.

I am not clear on which UDP header are we talking about. Is it the
header in the request sent by the MN, or the header that would be used
if the request was forwarded by the FA as a UDP packet?

MN authentication by AAA is based on the MAC in the MN-AAA
authenticator. When the MN creates the authenticator, it would have
calculated the MAC starting from the MIP reg header. If the FA adds
the UDP header to this AVP, then the MAC calculated by the AAA server
will not be the same. 

Unless the UDP header is the one in the request sent by the MN, and
the MN includes the UDP header in calculating the MN-AAA MAC,
this may not work.

Or am I missing something here? :-)

> AMR. But if what you will eventually need is an IP address why not send 

If the key is stored against an IP address, then using the FQDN still
needs DNS resolution, which we have accepted as not totally reliable.
So this "usage" can also be thrown out.

And yes, the FA-Host AVP would be redundant if the same info is send
in the MIP level. 

> with surprise for instance "It's not the CoA?"

Agree 100%. 

If we do store the FA-HA key against an IP-address, and not host
names, your solution #1 might be the way to go.

thanks,

Siva

---

From: Johan Johansson <[email-masked]>
Date: Fri, 05 Apr 2002 01:19:25 +0200

>Or am I missing something here? :-)
I was talking about the header that would have been added by the FA if 
the request had been forwarded as a UDP packet. The AAA server must then 
skip a UDP header at the beginning when calculating its MAC. I'm not 
saying that this is the optimal solution, but it seems to work in theory 
(I think).

j