Subject: RE: [NSIS] Tying the requests to the flows exploiting them

From: "Allen, Keith" <[email-masked]>
Date: Fri, 18 Jan 2002 13:13:02 -0600

Hello.
 
I would like to see the NSIS protocol enable the user to specify during call
(or "session" or whatever) establishment the means by which the packets that
identified as part are part of the call very flexibly.  So, for example, for
one call the user might send packets with an MPLS label value agreed upon by
the user and the network.  On another call the user might send packets with
given source and destination IP addresses, and given source and destination
TCP port numbers.  In the first example, the MPLS label value is exchanged
in the signaling messages.  In the second, the IP addresses and port numbers
are exchanged. 
 
I wouldn't think forgeability would be an issue.  If the user slaps an MPLS
label value specified as part of a call on a packet that is not really part
of the call, well, it is now.  The network will always check to see if the
user is trying to exceed their QoS parameters and shape or drop or reduce
the priority of those packets that are beyond the limits.
 
So, I guess my philosophy could be stated that the parties on either side of
the interface trust the other to correctly identify which packets are part
of a call, but still check to make sure the traffic isn't exceeding the
agreed-upon limits.
 
Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked] <mailto:[email-masked]> 
 
-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Friday, January 18, 2002 11:46 AM
To: Nsis (E-mail)
Subject: [NSIS] Tying the requests to the flows exploiting them
 
Hi. 
Nsis is targeting the setup of QoS paths across multiple domains potentially
belonging to several organisations that don't trust each other.  This has
been reflected in the proposals for the internal operation of the protocol
where extensive security requirements are proposed (Sec 5.8).  What appears
to be missing are equivalently stringent means for ensuring that domains
that authorise a QoS path can tell that the packets using that path are
actually the ones that should be using it.
In the simpler world of Intserv and Diffserv, requested QoS is invoked by
simple pattern matching on some combination of the packet header fields, but
even here thare has been a good deal of heart searching about how to ensure
that only the right packets can exploit better treatment from a network
(sub-text: only get what they paid for).  To do this properly seems to need
two things:
- The QoS protocol must be able to carry back to the end host making the
request from each QoS domain, a seed for unforgeable tokens which can be
attached to packets belonging to flow(s) which are to exploit the QoS path
setup by the request.
- The end host must be able to generate and attach suitable unforgeable
tokens to each packet in a flow that should receive the requested treatment,
which may then be tested by each QoS domain through which the packet passes.
Regards, 
Elwyn  
----------------------------------------------------------------------------
------ 
Elwyn B Davies 
        Routing and Addressing Strategy Prime 
        Portfolio Integration                   Solutions Ready         
        Nortel Networks plc                     Email:
[email-masked] 
        Harlow Laboratories                             ESN
6-742-5498 
        London Road, Harlow,                    Direct Line
+44-1279-405498 
        Essex, CM17 9NA, UK                     Fax
+44-1279-402047 
        Registered Office:                      Maidenhead Office Park,
Westacott Way, 
        Company No. 3937799                     Maidenhead, Berkshire, SSL6
3QH 
----------------------------------------------------------------------------

This message may contain information proprietary to Nortel Networks plc so
any 
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited. 
----------------------------------------------------------------------------

"The Folly is mostly mine" 
and the opinions are mine and not those of my employer. 
============================================================================
======

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 28 Jan 2002 12:19:15 -0600

Hi Marcus, Elwynd:

This is an interesting point. Has anyone advocated generating a token by
encrypting successively at each domain in a destination to source direction.

Marco 

> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 10:50 AM
> To: Elwyn Davies; Nsis (E-mail)
> Subject: Re: [NSIS] Tying the requests to the flows exploiting them
> 
> 
> Elwynd,
> 
> This is a very critical point, and we have been thinking 
> about it for quite 
> some time, but found no solution which is suitable (some or 
> to expensive in 
> terms of a overhead, others are only peodo secure :-). It is 
> getting very 
> important at the time a user pays for QoS (as you said).
> 
> I think it boils down to the problem, that an source IP 
> address does not 
> tell you something about the user sittin behind.
> 
> Marcus
> 
> --On Friday, January 18, 2002 5:45 PM +0000 Elwyn Davies 
> <[email-masked]> wrote:
> 
> >
> > Hi.
> >
> > Nsis is targeting the setup of QoS paths across multiple domains
> > potentially belonging to several organisations that don't trust each
> > other.  This has been reflected in the proposals for the internal
> > operation of the protocol where extensive security requirements are
> > proposed (Sec 5.8).  What appears to be missing are equivalently
> > stringent means for ensuring that domains that authorise a 
> QoS path can
> > tell that the packets using that path are actually the ones 
> that should
> > be using it.
> >
> > simple pattern matching on some combination of the packet 
> header fields,
> > but even here thare has been a good deal of heart searching 
> about how to
> > ensure that only the right packets can exploit better 
> treatment from a
> > network (sub-text: only get what they paid for).  To do 
> this properly
> > seems to need two things:
> >
> > attached to packets belonging to flow(s) which are to 
> exploit the QoS
> > path setup by the request.
> >
> > tokens to each packet in a flow that should receive the requested
> > treatment, which may then be tested by each QoS domain 
> through which the
> > packet passes.
> >
> > Regards,
> > Elwyn
> >
> > 
> --------------------------------------------------------------
> -----------
> > ---------
> >
> > Elwyn B Davies
> >
> > [email-masked]          Harlow Laboratories
> > ESN                     6-742-5498          London Road, Harlow,
> > Direct Line             +44-1279-405498          Essex, CM17 9NA, UK
> > Fax                     +44-1279-402047          Registered Office:
> > Maidenhead Office Park, Westacott Way,          Company No. 3937799
> > Maidenhead, Berkshire, SSL6 3QH
> > 
> --------------------------------------------------------------
> -----------
> > ---  This message may contain information proprietary to 
> Nortel Networks
> > plc so any  unauthorised disclosure, copying or distribution of its
> > contents is strictly prohibited.
> > 
> --------------------------------------------------------------
> -----------
> > ---  "The Folly is mostly mine"
> ==============================================================
> ===========
> > =========
> >
> >
> >
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis