Subject: RE: multiples PAAs

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 13 Mar 2003 10:37:17 +0100

hi yacine,

you raised an interesting issue. we initially wanted to include some text
about working assumptions to the draft but we removed it since it is covered
in the text (somewhere). you are addressing an assumption made about the
topology:

----------------

Topology Knowledge

Whenever the EP and the PAA are not physically co-located there is a
possible danger that the data traffic passes the wrong device (i.e. the
device where the Device Identifier is installed). Hence it is assumed that a
device in the access network is aware of the topology and is able to trigger
Device Identifier installation at the correct EP. Based on this topology
constraint the PANA protocol is executed between two nodes which are on the
same link. Installing packet filters on devices which are somewhere along
the path is therefore not possible with the PANA protocol itself because of
this topology problem. Other working groups such as the NSIS wg try to
address the problem of installing state at devices along the path in a more
generic fashion. 

----------------

hence the paa(s) must be able
- to determine at which ep the data traffic enters
- to signaling the necessary information to this device (if something has to
be installed there).

you might want to take a look at
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-01.txt
to see what happens if you want to signal packet filter information to
devices in the generic case. to make pana less complex some assumptions had
to be made. once you signal packet filter information to devices which are
one AS away then you experience problems due to the routing assymmetry (i.e.
you have to signal unidirectional packet filter information). 

do you think that we should add some working assumptions to the document?
should we somewhere capture your issue in a draft (if yes, which one)?

ciao
hannes

> Hi all,
> 
> "Discovery and Initial Handshake Phase" text in the protocol draft:
>     There can be multiple PAAs on the link.  The result does 
> not depend
>     on which PAA PaC chooses. By default PaC chooses the PAA that sent
>     the first response.
> 
> IMHO, there is a need to clarify here. Let's assume that we have 
> multiple PAAs separated from EPs:
> 
>              PaC1a --+            +- PAA1
>                      |            |
>              PaC1b --+-- EP1 -----+- router -----+
>                                   |              |
>               PaC2 ----- EP2 --- -+              |
>                                   |              |
>               PaC2 ----- EP3 -----+- router -----+----- (AAA)
>                                   |
>                                   +- PAA2
> 
> I mean if:
> - PAA1 provisions EP1
> - PAA2 provisions EP2 and EP3
> then it should be this way:
> - PAA1 authenticates Pac1a and PaC1b
> - PAA2 authenticates PaC2 and PaC3
> 
> it should be stated that the PAA which authenticates the PaC 
> should be 
> the same as the one which provisions the corresponding EP(s).
> 
> thanks,
> yacine
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 31 Mar 2003 16:37:20 -0800

Hi Yacine,

>>> so far the reasons for having multiples PAAs are:
>>> a) redundancy (a.k.a. fault-tolerance, backup PAA, etc.)
>>> b) administrative coverage (one PAA per ISP)
>>> 
>>> I would suggest also:
>>> c) distributed authentication (2 PAAs sharing all PaCs load)
>>> d) topological coverage (one PAA per access area)
>>> 
>>> a combination of any cases should be acceptable.
>>> 
>> 
>> If you look at the current protocol spec, you'd see only (a) can be handled.
> 
> 
> indeed the current protocol spec says that only (c) is handled [extract
> from the discovery section]:
> 
>   There can be multiple PAAs on the link.  The result does not depend
> this text states clearly that the 2 PAAs plays an identical role =>(c).

OK, as long as we do not expect any coordination (e.g., database
synchronization, etc.) among PAAs then (c) is covered. A PaC must pick one
PAA and keep using the same PAA throughout the PANA session. At any time
only one PAA keeps state for a given PaC. If these are the assumptions, than
that's fine.

> 
> can you please elaborate on how you intend to realize (a) without
> assuming PAA-PAA communication.

if (a) is the case where statet per PaC is replicated accross PAAs although
PaC uses PANA with only one of them, then you are right, this is not readily
doable with the current approach. It needs PAA-PAA communication which PANA
does not provide.

> 
> 
>> (b), (c), and (d) are not addressed, because we need to understand these
>> scenarios first. We had a discussion on at least (b) earlier, and it was not
>> clear if that scenario was really needed. Note that these additional
>> scenarios all incur extra complexity, hence their inclusion in the solution
>> requires justification.
> 
> 
> may I add that, without saying it clearly, you also had ealier
> discussions about (d) for example: when talking about handovers in the
> mobility context.

I presume you are talking about enabling fast re-authentication when PAA
changes. I don't think we have studied this area yet... This might require a
inter-PAA protocol (e.g., context transfers) in addition to some
modifications to PANA.

alper