Subject: [AAA-WG]: [issue] Handling of Home-Agent-In-Foreign-Network flag

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 27 Feb 2002 18:15:35 -0500

Issue :         Handling of Home-Agent-In-Foreign-Network flag 
Submitter name: Bob Kopacz 
Submitter email address: [email-masked] 
Date first submitted: 02-27-2002 
Reference: 
Document:       draft-mobileip-08 
Comment type:   Technical 
Priority:       1 
Section: 

Rationale/Explanation of issue: 

  (1) It is difficult for the originating AAAF to correctly set the
  Home-Agent-In-Foreign-Network flag.  That is, suppose the MN sends a
  "real" HA IP address (not all zeroes or all ones).  The AAAF only sees
  an IP address.  The AAAF doesn't know just from the HA's IP address
  whether that represents an HA in the home network, or an HA in another
  foreign network.  And maybe doesn't even know if the IP address is in
  his own network.  

  The AAAF would have to call upon the DNS or other external resources
  to make this "home-agent-is-in-a-foreign-network" determination. This
  introduces unnecessary delay into the call setup by duplicating work
  which the AAAH has to do anyway upon receiving the AMR.  That is, when
  the AAAH receives the AMR with a specified HA IP address, the AAAH has
  to map this IP address into the HA's realm and HA's DiameterIdentity,
  which will be used as the Destination-Realm and Destination-Host of
  the HAR.  Furthermore, the AAAH may be able to make this determination
  more quickly than the AAAF, as a session-stateful AAAH may well have
  this information at hand as part of his session state.

  (2) The proposal here is to make the Home-Agent-In-Foreign-Network flag
  one which is not set by the originating-AAAF, but is instead set by
  the AAAH.  This information will be returned to the originating-AAAF
  and FA when the updated feature vector is returned in the AMA.

  (3) It may be that the originating AAAF wants to disallow a foreign
  HA, or allow a foreign HA but only if the foreign HA is in the
  originating AAAF's domain.  If this capability is desired, then two
  new flags, settable by the originating AAAF, can be added to the
  MIP-Feature-Vector:

      Foreign-HA-Allowed-In-NonOriginating-Network
      Foreign-HA-Allowed-In-Originating-Network

  The AAAH, after examining the home agent's IP address and determining
  whether the HA resides in the originating network, home network, or
  some other foreign network, can examine the two new flags to enforce
  the originating AAAF's policy on foreign HAs.

  This way, the originating AAAF maintains the ability to place retrictions 
  on foreign HAs before the call is authorized.

  (4) If (3) above is considered something an originating AAAF wouldn't care
  about, then these two new flags can be removed from the proposal.

Requested change: 

  In section 1.2  Inter-Realm Mobile IP

  Replace:

    If the Mobile Node was successfully authenticated, the AAAH checks if
    the Home Agent was located in the foreign realm, by checking the
    Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.  If
    the flag is enabled, then the Home Agent is located in the foreign
    realm then AAAH sends an HAR message to AAAF which contains a MIP-
    Reg-Request AVP.

  With:

    If the Mobile Node was successfully authenticated, the AAAH checks if
    the Home Agent is located in a foreign realm.  If so, the AAAH sets the
    Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
    Only the AAAH may set the Home-Agent-In-Foreign-Network flag.

    If the Home Agent is located in a foreign realm other than the
    originating realm, and the
    Foreign-HA-Allowed-In-NonOriginating-Network flag is zero, then the
    AAAH will return an AMA with a Result-Code of
    DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

    If the Home Agent is located in the originating foreign realm, and the
    Foreign-HA-Allowed-In-Originating-Network flag is zero, then the AAAH
    will return an AMA with a Result-Code of
    DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

    Otherwise, if the Home Agent is in a foreign network, and this is
    allowed by both the originating AAAF and the AAAH, then the AAAH sends
    an HAR message to foreign HA which contains a MIP-Reg-Request AVP.

  - - -

  In section 1.4  Allocation of Home Agent in Foreign Network

  Remove this paragraph:

    In the event that the mobile node requests a home agent in the
    foreign network, and the AAAF authorizes its use, the AAAF MUST set
    the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
    This could happen when the AAA request is sent to "extend" a mobile
    node's current session.

  - - -

  In section 4.5  MIP-Feature-Vector AVP

  Replace:

    The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
    is added with flag values set by the Foreign Agent or by the AAAF
    owned by the same administrative domain as the Foreign Agent.  The
    Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
    message it sends to the AAAF.

  With:

    The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
    conveys flag values set by the Foreign Agent, the AAAF owned by the
    same administrative domain as the Foreign Agent, and the AAAH.  The
    flags in the MIP-Feature-Vector are updated as the AMR makes it way to
    the AAAH, and the updated MIP-Feature-Vector is returned in the AMA.

    The Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
    message it sends to the AAAF.

  - - -

  In section 4.5  MIP-Feature-Vector AVP

  To this list of flags:

    Flag values currently defined include:
         1   Mobile-Node-Home-Address-Requested
         2   Home-Address-Allocatable-Only-in-Home-Realm
         4   Home-Agent-Requested
         8   Foreign-Home-Agent-Available
         16  MN-HA-Key-Request
         32  MN-FA-Key-Request
         64  FA-HA-Key-Request
         128 Home-Agent-In-Foreign-Network
         256 Co-Located-Mobile-Node

  Add:

         512   Foreign-HA-Allowed-In-NonOriginating-Network
         1024  Foreign-HA-Allowed-In-Originating-Network

  - - -

  In section 4.5  MIP-Feature-Vector AVP

  Replace:

    If the mobile node requests a home agent in the foreign network
    either by setting the home address field to all ones, or by
    specifying a home agent in the foreign network, and the AAAF
    authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
    Network bit to one.

    The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and
    Home-Agent-In-Foreign-Network flag to one.

    When the AAAF receives the AMR message, it MUST first verify that the
    sender was an authorized Foreign Agent.  The AAAF then takes any
    actions indicated by the settings of the MIP-Feature-Vector AVP
    flags.  The AAAF then MAY set additional flags.Only the AAAF may set
    the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
    flags to one. This is done according to local administrative policy.
    When the AAAF has finished setting additional flags according to its
    local policy, then the AAAF transmits the AMR with the possibly
    modified MIP-Feature-Vector AVP to the AAAH.

  With:

    If the mobile node requests a home agent in the foreign network either
    by setting the home address field to all ones, or by specifying a home
    agent in the foreign network, and the AAAF authorizes the request, the
    AAAF may restrict the HA to certain networks by setting the
    Foreign-HA-Allowed-In-NonOriginating-Network and/or the
    Foreign-HA-Allowed-In-Originating-Network flag.

    The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available to one
    and the Foreign-HA-Allowed-In-Originating-Network flag to zero.

    When the AAAF receives the AMR message, it MUST first verify that the
    sender was an authorized Foreign Agent.  The AAAF then takes any
    actions indicated by the settings of the MIP-Feature-Vector AVP flags.
    The AAAF then MAY set additional flags.  Only the AAAF may set the
    Foreign-Home-Agent-Available, Foreign-HA-Allowed-In-Originating-
    Network, and Foreign-HA-Allowed-In-NonOriginating-Network flags to
    one.  This is done according to local administrative policy. When the
    AAAF has finished setting additional flags according to its local
    policy, then the AAAF transmits the AMR with the possibly modified
    MIP-Feature-Vector AVP to the AAAH.

  - - -

---

From: Tony Johansson <[email-masked]>
Date: Wed, 27 Feb 2002 21:47:26 -0800

Hi Bob,

please find comments embedded..

/Tony

>   which the AAAH has to do anyway upon receiving the AMR.

I don't really see why it should be so difficult for the AAAF to find out the
domain of the HA.

> That is, when

The whole idea with the MIP-Feature-Vector is to give info to the AAAH, which
the AAAH uses in its decision on how the HA allocation, etc can/shall be made.
Thus, it only the FA and AAAF that sets bits in the MIP-Feature-Vector.

>   originating AAAF's domain.

Right. So if the AAAF allows the HA to be kept, the AAAF forwards the AMR with
the Home-Agent-In-Foreign-Network flag set to one. If the AAAF disallow the HA
to be kept it would instead reject the request and return an AMA with negative
result code.

> If this capability is desired, then two

>   on foreign HAs before the call is authorized.

So what about if you want to configure the AAAF to say that it is ok to keep the
HA from some third party domains and not from some others? With this proposal,
the AAAH could only judge on NonOriginating-Network or Originating-Network,
which is very poor granularity for the originating AAAF's policy decisions on
foreign HAs.

Again, I would argue that the AAAF should handle its own policy decisions as we
have stated it today and I don't see why that is so difficult.

Regards,

/Tony