Subject: [Mip6] RE: a few comments on <draft-giaretta-mip6-aaa-ha-goals-00.txt>

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 08 Apr 2005 11:04:53 +0200

Hi Hannes,

thanks for your comments and sorry for the delay of my response.
Please see my comments below...(ccing also mip6 ML)

> 
> hi gerardo, 
> 
> i have finally read your draft 
> <draft-giaretta-mip6-aaa-ha-goals-00.txt>. 
> 
> here are a few comments: 
> 
> - avoid the usage of trust. this is just a very difficult 
> term with many
> different meanings. use security association instead. 
> 
>    The basic security model behind this draft assumes that the mobile 
>    node shares credentials with the AAA server 
>    of the MSP (AAAH), as stated in [2]. Furthermore the HA is 
> expected 
>    to have a security association with the AAAH server (see 
> Figure 1). 
>     
>  
>                      MN               AAAH              HA 
>                      ^                ^  ^               ^ 
>                      |                |  |               | 
>                      +----------------+  +---------------+ 
>                     Security Association  Security Association 
>                        [or Credential]
> 
>                           Figure 1 - Basic Model 
>     
> i know that the mip6 bootstrapping problem statement document 
> also uses the
> term extensively. i also dislike it there. 

I tried to use the same terminology adopted in the problem statement
draft in order to keep them coherent. This is the definition of trust
relationship in the last version of PS draft:

   Trust relationship
      In the context of this draft, trust relationship means that two
      parties in question, typically the user of the mobile host and the
      mobility or access service provider, have some sort of prior
      contact in which the mobile host was provisioned with credentials.
      These credentials allow the mobile host to authenticate itself to
      the mobility or access service authorizer and to prove its
      authorization to obtain service.

Which are your concerns with the usage of this terminology in these
drafts with regards to this particular definition? 

> i am not sure whether people are willing to revise the 
> bootstrapping ps
> document. i re-read it and came across a few things i would 
> like to see
> modified. 
> 

I guess there is still space to change the mip6 bootstrapping problem
statement document. Alpesh is still working on it.
It seems that this issue is mainly related to mip6 bootstrapping PS
draft. My idea for draft-giaretta-mip6-aaa-ha-goals is to keep the
terminology of the PS draft. So, no problem for me to change the
terminology here but only if it is changed also in the PS draft.

> - Scenario 4 is not quite clear to me. it does not seem to 
> help with most of
> the bootstrapping actions. 
> authorization based on the location (whatever location means 
> here) seems to
> be difficult. actually i do not know whether you use the term 
> location as
> discussed in <draft-ietf-geopriv-radius-lo-02.txt> or as i 
> moved to a new
> location and got a new ip address. just two different things. 
> 

Scenario 4 is not related to dynamic bootstrapping. The point is:
suppose the MN is statically provisioned with the HA address and the HoA
and has a manually configured SA with its HA. In this scenario, how do
you perform the authorization procedure? The location of the MN (in the
sense that it has moved to a new location and got a new IP address) was
just an example; another could be the time of the day or whatever else
can be in the user profile.

Do you think that this scenario is not to be considered? 

> - regarding:
> "
>   G2.1 The AAA-HA interface should allow the use of Network Access 
>         Identifier (NAI) to identify the mobile node. 
> "
> 
> typically the nai is used to identify the entity that can be 
> associated with
> a legal person. 
> in fact it would be good to describe this aspect in more 
> detail. i haven't
> found a good discussion of this topic somewhere in the 
> literature. maybe
> someone else can point me to some literature. 
> 

The assumption in the draft is that there is a one-to-one matching
between the user and the MN. Do you see a possible issue in identifying
the user/MN with the NAI in the communication between the AAAH and the
HA?

> - regarding:
> 
> "
>    G2.3 The AAAH server should be able to enforce explicit 
> operational 
>         limitations and authorization restrictions on the HA (e.g. 
>         packet filters, QoS parameters). 
> "
> 
> could you elaborate a little bit more what you would like to 
> accomplish with
> this requirement?
> 

The HA is an anchor point, at least for bidirectional tunneling. For
this reason an operator might want to install policies on MN's traffic
exploiting that all bidirectional data is tunneled through the HA.

> - regarding:
> 
> "
>    G2.2 The HA should be able to query the AAAH server to verify 
>         Mobile IPv6 service authorization for the mobile node. 
> "
> 
> what is the idea? query without triggering any actions? 
> 

This is mainly related to scenarios 3 and 4. The HA, after receiving a
BU or during the IKE exchange, could get in touch with the AAAH in order
to authorize the user. Based on the response from the AAAH, the HA can
grant Mobile IPv6 service to the MN.

This might also be relevant for scenario 1. However, in this case the
AAA-HA communication is used also to authenticate the user.

> - regarding:
> 
> "
>    G2.2 The HA should be able to query the AAAH server to verify 
>         Mobile IPv6 service authorization for the mobile node. 
> "
> what state would you like to retrieve? what should the aaah 
> do with the
> state? 
> 

I think you are referring to goal G2.7.

"
G2.7	The AAAH server should be able to retreive the Mobile IPv6 state
associated to a specific MN from the correspondent HA. This may be
useful to periodically verify the Mobile IPv6 service status.
"

Suppose that the AAA architecture of the MSA/MSP is stateless and the
AAA server that handles MN re-authentications changes over time. If
bootstrapping is performed during network access, how the AAA server
knows that the MN is already registered with that HA? A possible
approach could be: the MN tells the AAA infrastructure that it is using
a particular HA and the AAA server verifies the MN's state on that HA.
See draft-giaretta-mip6-authorization-eap-02, section 5.2 for details.

> - regarding:
> 
> "
>    G5.1 The AAAH server should be able to poll the designated HA for 
>         the allocation of a Home Address to the MN. Optionally, the 
>         AAAH server can provide a set of hints for the 
> construction of 
>         the Home Address (e.g. a preferred Home Address or a 
> preferred 
>         Interface Identifier). 
> "
> 
> how would the message flow for this interaction look like?
> i only see two options here: 
>  * the ha selects one (and then it might not be necessary to 
> communicate it
> to the aaa server)
>  * the aaah selects one. 
> why do you see the need for polling?  
>  

this goal is related to scenario 2. The MIPv6 bootstrapping is performed
during network access authentication communicating with the AAAH. In
this case the MN does not communicate directly with the HA. For this
reason, it is the AAAH that has to send the HoA to the MN. As you
mention one possibility is that the AAAH selects one HoA by its own.
However, my idea is that it is better that the HA allocates the HoA
since it has the most updated vision on the addresses allocated in its
link (e.g. it could have a list of HoAs already taken).

> this question also relates to the next requirement, regarding:
> "   
>    G5.2 The HA should be able to communicate to the AAAH server the 
>         Home Address allocated to the MN. 
> "
> 
> what would the aaah do with the home address? 
> 

As mentioned above, the AAAH sends the HoA to the MN in scenario 2, but
the HoA is selected by the HA.

> - regarding 
> 
> "
>    G5.3 The AAAH server should be able to send to the HA the security 
>         data needed to setup the IPsec SA between the MN and the HA. 
>         Possible security data are the authentication method and the 
>         cryptographic material to be used for IKE bootstrapping. 
> "
> 
> i think this section should talk only about the ikev2 
> pre-shared secret
> (maybe ikev1). maybe you want to provide a solution for the mip6-auth
> protocol (but i am not sure). 
> 

This refers to:
- PSK for IKEv2
- PSK and peer authentication method for IKEv1 Phase 1

Moreover, we'd like to keep the requirements a bit general in order to
address also mip6-auth if it will be necessary.

> for ikev2 there are not further parameters that need to be 
> provided since
> there are no further options that can be specified. 
> 

agree. Different for IKEv1, though.

> one thing to discuss would be the issue of the identity used for
> authentication. you might for user identity confidentiality 
> reasons want to
> use one identity during the bootstrapping procedure and 
> another one for mip6
> usage. 
> 

could you please elaborate this point? don't you think this is more
related to the bootstrapping solution discussion?

Ciao,
--Gerardo

> ciao
> hannes

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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