[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] RE: policy control for AAA & common signalling application functi ons
hi robert,
to make it more clear i give you an example:
pana, ieee 802.1x, ikev2 all use the extensible authentication protocol. i
understood dave's mail as a question whether it is possible to move common
functionality into a separate layer. if many nslps actually use this
functionality then his question might be certainly valid.
btw, i plan to write a few lines on this issue for a discussion on the
interim meeting. this is, unfortunately, not an easy issue.
ciao
hannes
> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> Sent: Wednesday, May 26, 2004 2:53 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
>
>
> 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.
> > >
> >
>
> --
>
> 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