AAA
ARCH
The AAA Architecture (AAAarch) Research Group
meeting aug 10th. at 51th IETF in London, UK.
Minutes of the IRTF AAAARCH session August 10, 2001 during
IETF-51 in London by Guus Sliepen.
==============================================================================
AT: Arie Taal
BM: Bob Morgan
CdL: Cees de Laat
CH: Christian Hesselman
GC: Georg Carle
HS: Henry Sinnreich
JV: John Vollbrecht
WW: Walter Weiss
9:00 Welcome by Cees de
Laat and John Vollbrecht, agenda bashing and FNT.
9:05 Status drafts and
ongoing activities, Cees de Laat
Since Minneapolis:
- 1 new draft in AAAARCH, 1 in AUTH/RAP group
- 1 AUTH interim meeting in Utrecht
- 10 teleconference calls from the AUTH group
Participation/contribution was, in overall, poor.
Minor rechartering:
- Update to make it more correct
- Removed time limit (was short-lived, now is long-lived)
- Relation with GRID Forum and RAP WG
- Some rewording and minor changes in goals
Presentation of current drafts.
9:20 Content and QoS policies
in Multi-domain Heterogeneous Mobile Systems,
Christian Hesselman
Is about applications which live in highly heterogeneous systems (lots of
different technologies combined). Domain administrators control such an environment
using policies. Work is done on refining protocols and implementations.
JV: Are you expecting to do negotiations, what is the inter domain piece
in this?
CH: The ID thing is when roaming between technological&admin domains,
the protocol must discover the new channel list and available quality
-1: Are you aware of the problems in MobileIP? We are working on inter-access
technology there.
CH: This is in application layer, yours probably is IP?
-1: No we work on any level. We are interested in what kind of AAA is needed
when roaming.
CH: Discovering the next router is different from discovering the available
content at application level.
-1: The whole purpose of MobileIP is doing as much as you can beforehand,
it's for real-time applications.
-2: Can you clarify what you mean by roaming? Are services continually available
when roaming?
CH: yes
HS: Do you see any contradiction with the end-to-end architecture?
CH: I'm not sure, my first response is that connection between client and
gateway is end-to-end, the only state is maintained at the application level.
It's realistic to assume that Domain Administrators want to control how to
allocate resources. You need the gateway to enforce the policies. BTW, this
is just for broadcast applications.
CdL: The interesting part is that you are discussing roaming between different
technologies as well as between domains. How should we go forward with this
with respect to AAAARCH?
CH: If it is still interesting for you guys.
CdL: We might learn a lot about it, especially about inter-domain issues.
9:35 draft-ietf-rap-access-bind-00.txt,
Walter Weiss
In Minneapolis there was a lengthy discussion about the need of fewer protocols
at the edges of the network. We also felt there was a significant commonality
between work done in the RAP WG and AAAARCH RG.
DiffServ group specified a set of functions that was needed to facilitate
QoS. The PIB we propose has two new structures (functions). One is the Accessor,
the other is the actual messages that are sent between the Accessor and a
PDP. The Accessor classifies Out-of-Profile traffic and possibly reassigns
them to a new profile(?).
-3: There is a line between Meter and Queue. Does anything goes over there?
WW: All In-profile traffic. The Accessor makes it more flexible to determine
what to do with Out-of-Profile traffic.
BM: I'm pleased to see this stuff.
WW: I don't understand what you're saying. But the most important part is
that we distinguish between semantics and real objects.
We put the identifier in there to allow it to be bound correctly to already
authenticated credentials.
-4: You showed a serialisation in Accessors. That implies that there has
some primary knowledge about which accessor to access first. What is the
selection mechanism.
WW: There are points in the classical model called demux points and straight
pass-through points. In the semantics you define the criteria how demuxers
pass traffic to different pass-through points. The decision is done dynamically
based on the policies.
-5: It looks difficult for me to really implement. You have a DiffServ model
but for out-of-profile traffic you use an IntServ model. If you aggregate
the traffic why do you go to a single flow?
WW: In general, most scenarios are easy implementable, because they are configured
a flow creation time. It's not a significant performance/scalability issue.
DiffServ is primarily focused on addressing core network problems. At edges
it's not well specified, because there the criteria exist which traffic gets
into what aggregates. In the DiffServ model there is a model for specifying
how meters etc are specified, but that's dealt with at the edges of the network.
-5: So it's at the edge and not in the inside?
WW: No. We shouldn't focus on DiffServ here but on the mechanisms provided
by DiffServ.
10:30 Access Bind Issues, John
Vollbrecht
HS: The previous presentation, I found it flawless. You need 11 messages,
after that it was simplified. If you setup flow with RSVP it's another 6
messages. Then you have your application (for example VoIP using SIP), you
have another 15~20 messages. We are building a monster that's far worse than
the telephone network. Is it doable at all to have a simpler way, like charging
a flat premium(?)?
WW: First of all VoIP is one of the worst examples, because the sheer amount
of negotiation and the way it has been designed. One specific point is that
we reduce this to 2 messages of negotiation, maybe other protocols should
follow us. We have so many messages available is for flexibility. The other
thing is that authorisation is also very interesting for many other things.
JV: I do think that this provides a tool that can be as simple as you make
it.
10:40 draft-irtf-aaaarch-generic-pol-0.txt,
Arie Taal
Depends on generic structure draft and objects and message types draft. This
draft is here to be able to do simulation etc. The language must be rich
enough to catch all the concepts of the AAA architecture.
Driver policies correspond to request types. The Driver policies together
with the ASMs define the behaviour of a AAA server.
GC: Policy language in comparison with other languages. Why a new language,
is it a refinement of another language or does it have added capabilities,
how about Ponder of the IP security language?
AT: It was easier to come up with a new language because it is specifically
designed for our requirements.
GC: What is specific here that makes it difficult to other policy languages?
AT: Well it would be harder to take an existing language, to check if it
applies to the AAA architecture, and to describe in a draft why that language
is good then it is to just make our own language, because we don't need many
constructs for a policy language, existing languages are in general a lot
more complex.
JV: I was curious about the addressing of AVPs. Is there any self-referencing
kind of data structure or are there only URL style addressings?
AT: yes.
-6: You found a solution to send error messages. Is it defined how to handle
error messages?
AT: That should be defined in data objects and message types draft.
-7: How does your policy support delegation. (Pushed policies.)
CdL: Isn't that more a management issue?
-7: How do you know that when distributed policies that they are trusted?
Is the delegation allowed?
CdL: I'd love to see that on the mailing list.
-8: Types in language. Is there any type checking? If those policies are
written manually, then AVP might actually have a different type then specified
in the policy.
AT: This was just a choice.
CdL: Further discuss this on the mailing list.
11:10 draft-irtf-aaaarch-aaa-pol-1.txt,
Guus Sliepen
No changes, no comments, no response at all.
11:10 Shibboleth Project, Bob
Morgen
CdL: We should also dig into the GLOBUS environment and the ways they try
to do AAA in there, because that will be a profound middleware platform.
This was a successful meeting I think.
11:35 End of the IRTF AAAARCH session August 10, 2001 during IETF-51
in London.