Subject: RE: Comments on draft-ietf-pana-requirement-00.txt

From: George Tsirtsis <[email-masked]>
Date: Mon, 11 Mar 2002 08:56:05 -0500

Hi again,

I think Monet should mature a bit more before it places requirements to PANA
or anyone else. I am saying this in a very good-natured way just because the
scope of Monet and its applicability is still in flax and the work is in BOF
state.

Personally I think that a clean separation between the Mobile Network behind
an MR and the fixed or other network the MR is connected to is very
beneficial. Despite that, the current PANA model I think satisfies what
Hesham is suggesting and I explain.

In one model (the one I prefer) the MR is authenticated on the network, in
which case the MR needs a PaC while the AR implements a PAA.

  <----Monet--->
 EndNode------MR(Pac)-----------AR(PAA)

In the same model the EndNode can authenticate itself to the MR in which
case the EndNode runs a Pac and the MR runs a PAA. Note that the MR plays
the role of the AR for the EndNode.

  <--------Monet-------->
 EndNode(Pac)------(PAA)MR-----------AR
                       (AR)

In  the above case the Monet is a different administrative domain than the
access network. Both of the above authentications can happen in the same
deployment scenario since they are independent.

The model Hesham suggests, however, can be implemented using the PANA mode
where the PAA is not in the AR. In this case the EndNode implements a Pac as
before while the PAA is in the AR of the access network. Note that the MR
implements no MR function in this case, or it may also implement a PaC if it
needs to also be authenticated on the network. 

  <----Monet------->
 EndNode(Pac)------MR-----------(PAA)AR
                  (AR)

Now, the selection of the DI should be done carefully. The use of IP
addresses seems to be the most appropriate thing here since the AR(PAA) will
not be able to see the EndNode's MAC address due to the existence of the MR
in between.

Does this make sense?

George

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Monday, March 11, 2002 4:11 AM
To: Hesham Soliman (ERA); [email-masked]
Subject: Re: Comments on draft-ietf-pana-requirement-00.txt

Hesham,

>    PANA Client (PaC) 
>     
>          The entity wishing to obtain network access from a PANA  
>          authentication agent within a network. A PANA client is 
>          associated with a network device and a set of credentials to  
>          prove its identity within the scope of PANA.  
> 
> => Shouldn't we allow the PaC to be associated
> with more than one device? For example if a MR

MR stands for Mobile Routers as defined by
MONET (mobile networks) work. 
(for those not familiar with this acronym)...

> is trying to get access to a network, a reasonable
> model would be to allow the MR to run PANA
> on behalf of the network behind it. In this 
> case a PaC is authenticating more than one
> device. This is also an issue with allowing 
> the DI to be an IP address, there is a number
> of issues here apart from the monet case, like 
> privacy.

In the MR case, the DI can be a MAC address
and the packets forwarded by the MR on behalf
of the clients behind it shouldn't be a problem.

(you don't really want your MR to be aware of all
IP addresses of the clients in its mobile network and
do PANA for them)

If the ingress filtering of the access network is an issue,
probably MR has to reverse tunnel packets to a home
network, in which case the access network will only
see the IP address of the MR as the source of traffic.

Also, what is the privacy issue with the IP address as the DI?

> 
>   4.1.4. Identifiers 
> 
>    PANA SHOULD allow various types of identifiers to be used for the 
>    PaC (e.g., NAI, IP address, FQDN, etc.) 
>    PANA SHOULD allow various types of identifiers to be used as the DI 
>    (IP address, link-layer address, port number of a switch, etc.)  
> 
> => We have to mandate the support of at least one identifier 
> for interoperability. 

So, the requirements should say that the "PANA MUST mandate
at least one identifier", right? Just checking to make sure you are
not saying the requirements draft must set that one type.

> Also an editorial comment, it's probably better to
> separate DI from PaC identifier.

Thanks Hesham.

alper

> Hesham

---

From: Alexandru Petrescu<[email-masked]>
Date: 11 Mar 2002 15:43:25 +0100

> scope of Monet and its applicability is still in flax and the work is in BOF

Hi George,

I would qualify monet requirements as more open to solutions than just
"flax".

While involved in some of the requirements I had to cut a lot of text
in order to avoid prohibiting all kinds of solutions.  For example
this, related to AAA:

   Monet protocols should provide means for access control,
   authorization and authentication of hosts and routers visiting the
   monet.  At the same time, a monet's top mobile router must use
   access control, authorization and authentication when attaching to
   the fixed IP infrastructure.  The requirements for monets using AAA
   are based on the requirements of Mobile IP using AAA, see [].  In
   addition to this, monet-specific requirements are described below.

   The former case translates to employing AAA and PANA protocols
   (with or without modifications) within the monet to accept visiting
   mobile hosts or routers.  The latter case ensures the possibility
   of a mobile router to use AAA and PANA protocols (with or without
   modifications) to access the fixed IP infrastructure for itself and
   on behalf of its attached nodes.  Cases where interactions between
   the top MR and the access AAA entities (AAAL/Attendant) pass
   through MR's HA should be avoided.  Similarly, cases where a monet
   visits another monet and first-hop (AAA-type) and access control
   passes through any of monet's HA should be avoided.  This is to
   ensure that the PANA protocol entities communicate directly, and
   not through tunnels.

This is very much on par with the descriptions you just provided, that
I find very relevant.  In addition, monet's should probably support
cases where AAA/PANA is run only inside a monet and the monet is the
home and the infrastructure is not consulted.

But I was finding even that to be a bit restrictive.

Alex