Re: [NSIS] RE: policy control for AAA & common signalling applica tionfuncti ons

[David R Oran <oran at cisco.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 26, 2004, at 9:52 AM, Hancock, Robert wrote:

> Ok (this is what I expected). But in that case,
> the common functionality is the identification of
> the peer in the signalling relationship, and at least
> partly I suspect this is already provided by GIMPS
> (if applications want to use that function) - there
> are still some questions about how applications
> control/interact with the way that that identity is
> managed and verified (cf. Mike Richardson's security
> concerns).
>
> But I don't think this really has anything to do with
> policy control for AAA. (Hence my question might really
> be 'is this what Dave was talking about?')
Partly. The policy element might in fact be interested in just about 
any part of the NSIS message, which is part of what makes the problem 
hard when you try to separate NSIS into layers and still have a common 
interface to an external policy decision element. As with other parts 
of the NSIS architecture, I tend to fall in a slightly different place 
in the design spectrum from those who advocate strong separation among 
the NSLPs.

However, that is not the main point I was making way back in Seoul. It 
was the observation that there are some benefits to be obtained to 
having an explicit policy control object in NSIS, in a manner similar 
to the way policy control works in RSVP. This allows both asserted 
policy to be provided by the endpoint (which it may have obtained by a 
prior AAA exchange or via a token provided in an application signaling 
protocol like SIP) and to be modified and propagated to control the 
behavior of downstream or upstream policy checks.

Dave.

> r.
>
> -----Original Message-----
> From: john.loughney at nokia.com [mailto:john.loughney at nokia.com]
> Sent: 26 May 2004 14:15
> To: Hancock, Robert; hannes.tschofenig at siemens.com;
> Yacine.El_Mghazli at alcatel.fr; oran at cisco.com
> Cc: nsis at ietf.org
> Subject: RE: [NSIS] RE: policy control for AAA & common signalling
> applicationfuncti ons
>
>
> Hi Robert,
>
> > 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.
>
> The impact is that that the nodes may need to be able to extract a
> reasonable identity from the NSLP/NTLP for the AAA backhaul protocol.
>
> John
>
> --
>
> 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.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran at cisco.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAvJeNjWaEtlTdKuYRApCaAKDSFGBUVI4BxEf5IwJMm+Hw8fkrVgCfUH6Z
dxSDpEdLiTA40iD1whAg6SI=
=xbCL
-----END PGP SIGNATURE-----


_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis