Subject: Re: [Ieprep] Resource priority header

From: [email-masked]
Date: Thu, 23 May 2002 11:24:24 EDT

In a message dated 5/23/02 9:56:57 AM Eastern Daylight Time, [email-masked] 
writes:

> Ken,
> 
> > 
> > without duplicating Henning's earlier comments, I'll just reiterate
> > that the R-P header mechanism is just a means of conveying labels.
> > And thats a requirement that we have as originally discussed in
> > Baker's draft, and an objective stated in the Carlberg draft.
> > 
> 
> It is very easy to say about strings in SIP that they are labels for
> some external module, but someone has to evaluate the impact of
> of such a design for SIP processing. Notable here is that there is a
> strong impact on the security handling of a SIP message carrying one
> of these - the requirements for authentication and integrity are
> especially difficult since it seems likely that intermediaries need to 
> 

As I said in my presentation, I don't believe the procedures for 
authentication/authorization are any more difficult or different just because 
we add the Resource-priority header. One might consider it is a little more 
important to do A/A, but I don't believe it requires any stronger or 
different A/A than many other capabilities that SIP includes, like releasing 
or transferring someone else's call.

And I seem to remember several other discussions about the problems of 
providing security for fields which intermediaries might change. In this 
case, it is not just any intermediary that can change the Resource-priority 
header. In the architecture I presented in which each originator has a 
trusted proxy which provides originating service, that trusted proxy would 
check the authorization to use a particular priority level and change it, 
just as it might check the authorization to use lots of other things (which 
have been subscribed to). So the Resource-priority header does not introduce 
anything new in this regard.

> 
> There is also an impact on interoperability handling.  I didn't
> say it this way in my other message, but there are major tradeoffs
> (aka inherent conflicts) in the direction being discussed that 
> SIP and IP telephony entities invoke some local default policy for
> any label they receive that they don't understand.  It's hard to see
> how this squares in the Internet/heterogeneous deployment world with
> the IEPREP fundamental requirement of high probability of successful
> calling.  If the real tradeoff is that SIP implementations actually
> need to understand the majority of labels, then there's impact
> 

Here is where there is a major difference of concept of what the 
"heterogeneous" nature of handling traffic is. It is true that if a device 
has to be able to understand and correctly process every namespace and value 
defined (and registered with IANA) then there would be a problem (especially 
with text encoding). But I believe that, independent of the Resource-priority 
header, there must be some concept of a VPN, so that when a device (proxy, 
endpoint, etc) is processing a session setup it has some understanding of 
which VPN it is a part of. Otherwise, it could not apply the procedures 
required for that "network". I believe the requirements for DOD (and for any 
other "network") is that when looking at the Resource-priority header, it 
expects exactly one namespace and would consider everything else as "unknown" 
and indicative of some other fault (misrouting).

Yes, in some cases, there will be interoperability handling that needs to be 
defined, but the IETF doesn't need to be concerned with this. The DOD network 
may provide interworking with other networks, and will specify the 
appropriate mapping between the dsn namespace values and the values used in 
that other "public" network.

> 
> > on a different note..
> > 
> > > - Is it an appropriate feature in SIP architecture for a call request 
> for
> > >   one call to delay other arriving requests?  To cause ongoing calls to 
> > >   be terminated?
> > 
> > so while I'm agnostic as to whether such types of actions should be done,
> > I am concerned if one prevents SIP from just conveying information that
> > could trigger such action (either within IP telephony, or in the PSTN).
> > 
> 
> Only if the "just conveying" has a really good security and
> 

This question bothers me. The main point I've been making in a series of 
presentations is that the DOD requires the ability to give one call some 
preferential treatment over another. The DOD can not use SIP if this 
capability is not supported. However, whether the preferential treatment is 
in the form of "delaying" one call in preference to another, or causing a 
call to terminate, this treatment is not a part of SIP. SIP just carries the 
needed information.

> Finally, your last sentence raises my antennae about a different
> distinction:  the function of conveying the information from a SIP
> phone to a PSTN gateway for use in the PSTN, and the function of
> bridging the information between PSTN gateways across the SIP/IP
> net, are easier to engineer and secure than the functions in which
> the information invokes functions in the SIP/IP net.  I just spoke
> with Scott about this and he agreed that guidance to the group
> to keep them well distinguished (which he has given) may mean the
> 

Yes, this is a concern that needs to be adressed - how to be confident that 
the information is correct and authorized before using it to do something 
within the SIP/IP net. This again is the point of presuming a particular 
network architecture to provide the trust relationships. For example, when a 
priority value is received from the PSTN (probably using ISUP) via a gateway, 
it must be presumed that the PSTN has determined the authenticity of the 
request. There is then no issue for the SIP/IP net to believe the value and 
act on it.

> Allison
Mike Pierce

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 23 May 2002 11:10:30 -0700 (Pacific Daylight Time)

Hi,

> anything new in this regard.

I agree that this is not a new problem, but we also haven't come up with a
general purpose solution to this problem either.  The priority of the
end-to-middle and middle-to-end security requirement seems to be
approaching the top of the heap now though.

> that other "public" network.

I assume that you could also handle traffic with no resource-priority
namespace as "ordinary" low-priority traffic in any of these networks, and
that doing so would be a policy decision?

thanks,
-rohan

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

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 28 May 2002 08:13:16 -0400

At the IEPREP interim meeting on May 20th, several people spoke in favor of
including the US DOD's requirements for MLPP (Multi-Level Precedence &
Preemption) in with the IEPREP requirements.  Other people felt that this
was specific to the DOD and therefore should not be part of the IETF
standards.  This would result in the DOD writing their own standard to
support this requirement.  I think this would make things more difficult for
much of the industry.

I wanted to point out that priority calling is not just a US DOD
requirement.  Many of the US allies, such as the NATO countries, Australia,
and other nations have the same requirement.  This does not apply to a few
private networks.  The US DOD contracts with every major service provider
and there is no reason for this to change just because the technology is
changing.  This results in most major service providers having to meet these
standards in many if not all of their switches.  This in turn, means that
most (if not all) switch vendors will have to implement these functions.

I believe that the IETF has the expertise to do a better job on this work
and that one set of standards will result in less confusion and less trouble
for the various switch vendors.  I believe that integration with GSM (which
uses multiple priority levels) is also necessary.  I hope that the IEPREP WG
will include these requirements in its output.

Steve Silverman
Houston Associates

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 28 May 2002 09:00:30 -0400

On Tuesday, May 28, 2002, at 08:13 , Steve Silverman wrote:
> and other nations have the same requirement.

1)	The IETF is a *global* standards body, not one just for the US or
	just for NATO.  There was a time, long ago, when that wasn't strictly
	true, but that time is long since past.

2)	Further, the IETF has not yet seen folks from Australia or a number 
of other
	NATO countries speak up *here* about what their requirements are.  
So while
	your comment is interesting, it doesn't justify putting what (at 
the moment,
	given that the other countries you mention aren't participating 
directly *here*
	and telling us *directly* about their requirements) are US-centric 
requirements
	into a global standard.  And beyond that, there are a lot more 
countries
	that you don't claim to be in the set with similar requirements to 
US DoD
	than you claim to be in the set.

3) 	The Japanese description of their requirements/uses for IEPREP 
services vary
	significantly from US DoD's description, based on the Japanese 
presentations
	at past IETF meetings.

>  This does not apply to a few

	At least some service providers consider themselves "major" and yet
do not have a US DoD contract of this sort.

> standards in many if not all of their switches.

> This in turn, means that most (if not all) switch vendors will have to 
> implement
> these functions.

	Actually, it means that many of the switch vendors *who sell to the 
US market*
might decide to support the US DoD requirements.  That still does not 
justify
putting US-centric requirements into a global standard.

Ran
[email-masked]

PS:	I'm starting to wonder how many folks on this list (other than me) 
are *not*
	having their participation sponsored/paid for by the US 
Government.  IETF *does*
	frown on having any organisation, including DISA/NCS, try to pack 
an IETF WG
	with its supporters to try to dominate the results of the WG.
PPS: IETF doesn't vote precisely so that attempts to "stack the deck" 
won't work.

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 28 May 2002 16:37:27 +0100

hello,

> support this requirement.  I think this would make things more difficult for

since I didn't attend the meeting, its not possible for me to try and
articulate or explain the objections that were expressed at that time.

however, imo your request may be helped if you focus on requirements 
for supporting MLPP (an ITU standard), as opposed to the requirements
of a single organization.  Or, is it your opinion that DoD requirements 
with respect to MLPP are different than that which one would associate 
with the ITU I.225.3 standard?

assuming the requirements are roughly the same, I would imagine that
operational experience/input from different organizations would be
helpful.

-ken

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 28 May 2002 16:18:58 -0400

Ran,
How much of the user community should want a function before it is subject
to global standardization?  What percentage?  We don't usually know such
things in advance.  Most people don't think 3 months in advance let alone 5
years in advance.  That's why most standards groups that I have seen are
dominated by techies who work for switch vendors and a very few foresighted
service providers. Getting user requirements has always been quite
difficult.  Almost a demonstration of psychic powers :-)

In this case, both the US DOD and the GSM communities have indicated a
requirement for certain functions.  One has indicated that this function is
very important to them.  Is there any doubt that we would like the Internet
to interwork with GSM?  Much of Europe will need this function.
Even if something is only of interest to North America and Europe, that is a
large market that many vendors are interested in. Perhaps even some Japanese
vendors.

Consider the long discussion on Privacy in SIPPING.  What percentage of the
user community needs to make anonymous calls?  Can I knock on your door
while wearing a mask?  (Sorry for the digression.)  If 10% of the users want
something that can be done and are willing to pay for it, should we do it?
Or at least write the standards to allow it?

Steve Silverman    Houston Associates

PS.  We are all supposed to be experts representing ourselves rather than
our companies. At
the same time, my efforts are supported by my company who expects to make
money out of my efforts.  I think this is true for most of the participants
on this list.  How often do you
see someone do something greatly to the disadvantage of their employer.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> RJ Atkinson
> Sent: Tuesday, May 28, 2002 9:01 AM
> To: ieprep
> Subject: Re: [Ieprep] MLPP Requirements
>
>
>

---

From: Sean Donelan <[email-masked]>
Date: Tue, 28 May 2002 18:09:31 -0400 (EDT)

> things in advance.  Most people don't think 3 months in advance let alone 5

The issue with standardizing is it then impedes other user of the same
bits for other things people may find useful.  So the question remains,
must it be universially standardized, or only subject to local
negotiations between the carrier of choice and DoD.  Otherwise, we end
up unsetting all that junk so it doesn't interfere with what we want to
do.

interface ethernet 0
ip address xxx.xxx.xxx.xxx
ip route-cache policy
ip policy route-map SET-PREC
no ip directed-broadcast
!
route-map SET-PREC permit 10
match ip address 160
set ip precedence routine
!
access-list 160 permit ip any any precedence priority
access-list 160 permit ip any any precedence immediate
access-list 160 permit ip any any precedence flash
access-list 160 permit ip any any precedence flash-override
access-list 160 permit ip any any precedence critical
access-list 160 permit ip any any precedence internet
access-list 160 permit ip any any precedence network
!

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 May 2002 18:14:56 -0400

There are two separate issues:

- The basic mechanism

- the various namespaces (such as DoD)

I think it would be helpful to keep these separate. For some parts, such 
as Resource-Priority, there is no great harm of having several 
namespaces in parallel, as long as the number is small. There is no 
shortage of identifiers, so if the Republic of Burma wakes up to the 
need of having emergency priority in a few years, they can add this 
without being disadvantaged by their late arrival to the working group.

This may argue for splitting drafts just to get away from the naming 
discussions.

This discussion seems rather abstract at the moment.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 28 May 2002 21:07:58 -0400

On Tuesday, May 28, 2002, at 04:18 , Steve Silverman wrote:
> things in advance.
	
	In the IETF, we often understand the breadth of demand before
standardisation.  I can't speak for other fora.

> while wearing a mask?  (Sorry for the digression.)

	IETF has *required* such topics to be discussed and addressed in
depth for many many years.  And by long-standing IETF policy, those
particular topics must be addressed even if a large percentage of
the user community doesn't want them.

> Or at least write the standards to allow it?

	Nothing I've said was along the lines of "preclude X".  Rather,
I've consistently said that "before we require X of *everyone*,
we need to see broad support for that X across the globe".  It is
a fine thing to say "we like to ensure that X isn't prohibited".
I haven't seen that comment yet.  I've been reading "X must be
mandated (of everyone)", which just isn't supported by the limited
participation happening here so far.

> our companies.

	Yes, though that isn't precisely what seems to be happening here,
sigh.  Rather we seem to have a WG primarily paid for by DISA/NCS,
that lacks the broad diversity present in the WG handling SIP.  For
example, the details of whether/how SIP might be altered *ought* be 
determined
*by the SIP community as a whole*, rather than some subset as is 
happening here.

>  At

	Happens pretty regularly in several other IETF WGs that I'm 
familiar with,
because some folks understand that the goal of the IETF is NOT company 
profit,
but instead the health and growth of the Internet.  And if that sounds 
idealistic,
yes I am that idealistic about that topic.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 28 May 2002 21:50:02 -0400

> with the ITU I.225.3 standard?

	The above would be a helpful approach, IMHO, to the extent it got 
us above
the tree tops of the NCS forest and high enough up that we could
address MLPP generically in a way that could fit many countries needs
-- recognising that one size does not fit all and that different
telephone administrations (e.g. US, JP) do articulate different 
objectives
in their IETF presentations so far.

	In particular, it is not at all clear to me that each network that
supports precedence needs to implement that support in exactly the
same manner.  So if the requirement could be abstracted a fair bit,
as Fred's note of a few days ago suggested, that would seem clever
(to me at least).  Then another WG (e.g. working on SIP) could take
the high-level abstract requirement and translate it into zero or more
protocol changes to the protocols in that other WG.

	In a lot of cases, I suspect that clever re-use of existing Internet
mechanisms can solve a lot of the actual needs.  I believe Fred's
draft talks about this, among other things.

Ran
[email-masked]

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 29 May 2002 14:30:07 +0100

> This may argue for splitting drafts just to get away from the naming 

I think it would be a real shame to not include a simple example set of 
labels in the draft as it exists now.  but if it simplifies the process
of advancing the mechanism (the mechanism obviously being beyond the scope
of this group), then I would concur with the thought of splitting the
document.

> This discussion seems rather abstract at the moment.

quite agreed.

-ken