[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] RE: policy control for AAA & common signalling application functi ons
it's utterly clear that some of the information needs
to match since otherwise the answer from the AAA protocol
would not match the question in the NSLP protocol.
but that is not helping us to work out what would
be common among different NSLP protocols. or, how the
need to be able to use AAA protocols impact on some
common part of the NSLP design. AFAICT this might be
something to do with peer identification for example
(but that could be more of a GIMPS issue even).
r.
> -----Original Message-----
> From: Tschofenig Hannes [mailto:hannes.tschofenig at siemens.com]
> Sent: Wednesday, May 26, 2004 1:49 PM
> To: Hancock, Robert; 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> Cc: nsis at ietf.org
> Subject: RE: policy control for AAA & common signalling application
> functi ons
>
>
> hi robert,
>
> if you look at the following figure (copy-and-paste from
> section 3.3 of
> <draft-ietf-nsis-qos-nslp-03.txt>):
>
> +-------------+
> | Entity |
> | authorizing |
> | resource |
> | request |
> +-----+-------+
> |
> |
> /-\----+-----/\
> //// \\\\
> || ||
> | AAA Cloud |
> || ||
> \\\\ ////
> \-------+-----/
> |
> +-------------+ QoS signaling +---+--+
> | Entity |<=================>| |<=========>
> | requesting | Data Flow | QNE |
> | resource |-------------------|------|---------->
> +-------------+ +------+
>
>
> the information carried
> - between the end host and the QNE and
> - the QNE and the AAA infrastructure
> needs to match.
>
> there are certainly some requirements on the protocol handling on both
> protocols.
>
> ciao
> hannes
>
>
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> > Sent: Wednesday, May 26, 2004 2:09 PM
> > To: Tschofenig Hannes; 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> > Cc: nsis at ietf.org
> > Subject: RE: policy control for AAA & common signalling application
> > functi ons
> >
> >
> > this is part of what I think is being discussed.
> >
> > i think a very reasonable deployment approach is to consider
> > that node B uses a backhaul protocol (like radius or diameter
> > or cops or even ldap or ...) to find out the answer, and that
> > how to do this shouldn't be re-invented for every different
> > type of answer that one wants. but i'm not certain how much
> > impact this should have on the wire protocol itself as compared
> > to the implementation inside the node.
> >
> > r.
> >
> > -----Original Message-----
> > From: Tschofenig Hannes [mailto:hannes.tschofenig at siemens.com]
> > Sent: Wednesday, May 26, 2004 12:17 PM
> > To: Hancock, Robert; 'Yacine.El_Mghazli at alcatel.fr'; David Oran
> > Cc: nsis at ietf.org
> > Subject: 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
> > >
> >
> > --
> >
> > Visit our website at www.roke.co.uk
> >
> > Registered Office: Roke Manor Research Ltd, Siemens House,
> > Oldbury, Bracknell,
> > Berkshire. RG12 8FZ
> >
> > The information contained in this e-mail and any attachments
> > is confidential to
> > Roke Manor Research Ltd and must not be passed to any third
> > party without
> > permission. This communication is for information only and
> > shall not create or
> > change any contractual relationship.
> >
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis