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.

CdL - aug 12th 2001 Visitors of this page: