[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] policy control for AAA & common signalling application functions
hi robert,
hi dave,
dave, you raised a very interesting issue in one of your mails:
"is the aaa functionality a common part for all applications? "
apart from the fact that the term "AAA" is confusing which i had to notice
already with one of my previous drafts i think that this is a perfectly
valid question. in fact i came accross this issue in our work on the nat/fw
nslp.
in particular you seem to point to the following problem:
- you have an nsis node A and an nsis node B.
- nsis node A needs to authenticate itself to node B and more important to
be authorized todo certain actions.
- however, node B might not be able to make this decision. instead it needs
to ask another third entity to make this decision.
is my interpretation on this correct?
ciao
hannes
> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> Sent: Monday, May 24, 2004 5:59 PM
> To: 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> Cc: nsis at ietf.org
> Subject: RE: [NSIS] common signalling application functions
>
>
> [Apologies for the late reply:]
>
> Hi,
>
> Considering the various options discussed:
>
> 1. I suspect it's nicer to have a dedicated toolbox that to
> have re-use bits and pieces of insides of NSLPs (at least at an
> early stage). But that requires more work and organisation and
> documents, so it's really a question of energy ("good stuff"
> as Dave describes it does not come free.) After repeated calls
> for input on this subject during the framework development, we
> didn't get very far (Bob made similar comments when the purpose
> of the signalling analysis work was being discussed), so I think
> it's probably best to consider addressing these problems in a
> 'bottom up' way at least for now.
>
> 2. I'm opposed to integrating this stuff into GIMPS. GIMPS
> has enough non-trivial things to do without adding more things
> which don't have a strong interaction with its transport
> functions.
>
> 3. I checked Dave's list of common functions to see how these
> things are currently being progressed, if at all. Here is my
> perception:
>
> *) precedence and pre-emption: the QoS model people have included
> a proposal in their latest draft. That could be evaluated from the
> perspective of other application users.
>
> *) separation of reserve and commit phases: at the moment, I still
> don't see _how_ this can be treated independently of the resource
> description issue (not why it is necessary to do so), and why
> finessing it as part of the resource description is a bad idea.
>
> *) fate sharing: if this is a reference to wanting the state installed
> for one application to be conditional on the state installed for
> another application in failure cases, this was actually discussed
> at length in the requirements phase and agreed to be a
> non-requirement.
> The reason is that it can get almost unboundedly complex to do this
> in the network, and you can never do as good a job as in the end
> system; so, why go for extra efficiency in the form of network support
> when this is just to handle exceptional (failure) cases. but see
> also the next point:
>
> *) inter-nslp binding: there probably is an issue about setting up
> signalling state for multiple signalling applications needing
> inter-NSLP interactions and hence possibly several round trips.
> I think we need examples of this to work on understanding what a
> general solution would look like. We do know there is a problem with
> NAT/other-NSLP interactions, but that is also a problem which affect
> GIMPS as well, so I would like to see how that works out before
> considering the case extending to a more general concern.
>
> *) policy control for AAA, etc.: I have to admit I don't really
> understand this one. If it is a matter of having unified handling
> of NSIS resource requests in the context of a AAA architecture, it
> is clearly a Good Thing; however, how much does it relate to common
> interactions within a node rather than having an impact on the wire
> NSIS protocols themselves?
>
> *) route recording: i can see this as being a common (i.e. shareable)
> object - provided the applications can agree on what information about
> the route to record (node ingress address, node egress address, ports,
> node FQDNs...). I think this sort of thing would best be handled
> as a set of common diagnostic objects; Xiaoming has already done
> some thinking here AFAIK.
>
> *) explicit routing: *IF* this was to be supported as a function I
> think it would have to be in the transport in some form. I raised
> a previous email on whether this would ever be the case (i.e. in what
> sense explicit routing would be part of NSIS scope) which
> didn't really
> get discussed much (see the archive around 20/04); in any case,
> it is becoming clearer how to fit variable message routing methods
> into GIMPS (NATFW requires it IIRC) and this would just be one more.
>
> *) resource sharing: i think this has to be in the NSLP.
>
> So, at the moment, while seeing that it is probably a good thing
> for the NSIS 'architecture' to enable some commonality between
> signalling applications, the best specific cases are already being
> worked on.
>
> robert h.
>
> > -----Original Message-----
> > From: Yacine.El_Mghazli at alcatel.fr
> > [mailto:Yacine.El_Mghazli at alcatel.fr]
> > Sent: Friday, April 30, 2004 15:24
> > To: David Oran
> > Cc: john.loughney at nokia.com; Ruediger.Geib at t-systems.com; Hancock,
> > Robert; nsis at ietf.org; Tschofenig Hannes
> > Subject: Re: [NSIS] common signalling application functions (was RE:
> > Tentative Interi m Meeting schedule)
> >
> >
> > dear all,
> >
> > I participated into the design of the AAA in the QoS-NSLP
> > together with
> > hannes. I tend to agree that this should fall into the
> > so-called 'common
> > sig app functions' block.
> >
> > moreover when examinating the dave's list of targetted
> > applications, we
> > could even narrow the scope of such a common block to AAA
> (at large...
> > let's say 'policy'). concerning the design alternative
> > (rüdiger mentions
> > 'toolbox' vs. cross-ref between NSLPs), IMO the first one
> > should lead to
> > a cleaner design and avoid doing twice the same thing.
> >
> > I have finally a couple of comments/questions:
> >
> > 1) did you consider integrating such a generic 'toolbox' into
> > GIMPS ? or
> > maybe the WG wants GIMPS to keep strictly relating to transport ?
> >
> > I would suggest to copy the RSVP design here: a generic
> > POLICY_DATA TLV
> > in GIMPS, which contains a list of Policy Element (PE)
> objects. those
> > PEs would be designed separately and I'm pretty sure a couple
> > of already
> > RFCed PEs could even be re-used as is.
> >
> > 2) does the working group think that the design of such
> > generic objects
> > will come together with some kind of framework ? authz protocols ?
> > requirements ?
> >
> >
> > thanks,
> > yacine
> >
> >
> >
> >
> >
> > David Oran wrote:
> >
> > > --On Thursday, April 29, 2004 1:09 PM +0300
> john.loughney at nokia.com
> > > wrote:
> > >
> > >> Robert,
> > >>
> > >>> The 2nd approach doesn't sound very different from how Diameter
> > >>> was designed, with multiple application support. Would
> that be a
> > >>> good analogy, or were you thinking of something different?
> > >>
> > >>
> > >> Rüdiger's mail arrived first, so I didn't see your mail where you
> > >> suggested it was Diameter-like ...
> > >>
> > >> Anyhow, I support your suggestion. Dave, would this
> address your
> > >> concerns at all?
> > >>
> > > It solves the pragmatic problems of encoding and abstract
> > syntax, but
> > > by itself does not ensure that the design of the common
> functions is
> > > in fact carefully done with the goal of generality and
> extensibility
> > > across NLSPs.
> > >
> > > So, this is progress, yes.
> > >
> > > Many of these common functions have impact similar to designing an
> > > NLSP itself. It would be good if we could tackle them
> directly with
> > > people identified to do the work and ensure it meets the
> > needs of the
> > > NLSPs we know about and that the specification is clean clear, and
> > > all that other good stuff.
> > >
> > > I think we still need further discussion of the related
> problem of
> > > ordering among NLSPs so that things like NAT translations and QoS
> > > flow classifiers work together and don't need multiple RTTs to
> > > establish state.
> > >
> > > Dave.
> > >
> > >
> > >> John
> > >>
> > >> _______________________________________________ nsis
> mailing list
> > >> nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________ nsis mailing list
> > > nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
> > >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis