1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group A. Beck
Request for Comments: 3836 M. Hofmann
Category: Informational Lucent Technologies
H. Orman
Purple Streak Development
R. Penno
Nortel Networks
A. Terzis
Johns Hopkins University
August 2004
<span class="h1">Requirements for Open Pluggable Edge Services (OPES)</span>
<span class="h1">Callout Protocols</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document specifies the requirements that the OPES (Open
Pluggable Edge Services) callout protocol must satisfy in order to
support the remote execution of OPES services. The requirements are
intended to help evaluate possible protocol candidates, as well as to
guide the development of such protocols.
<span class="grey">Beck, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
Table of Contents
<a href="#section-1">1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Functional Requirements . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Reliability . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Congestion Avoidance . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Callout Transactions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.4">3.4</a>. Callout Connections . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.5">3.5</a>. Asynchronous Message Exchange . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.6">3.6</a>. Message Segmentation . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.7">3.7</a>. Support for Keep-Alive Mechanism . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.8">3.8</a>. Operation in NAT Environments . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.9">3.9</a>. Multiple Callout Servers . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.10">3.10</a>. Multiple OPES Processors . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.11">3.11</a>. Support for Different Application Protocols . . . . . . <a href="#page-7">7</a>
<a href="#section-3.12">3.12</a>. Capability and Parameter Negotiations . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.13">3.13</a>. Meta Data and Instructions . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Performance Requirements . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Protocol Efficiency . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Requirements . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Authentication, Confidentiality, and Integrity . . . . <a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Hop-by-Hop Confidentiality. . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Operation Across Untrusted Domains. . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.4">5.4</a>. Privacy . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. References. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Normative References. . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7.2">7.2</a>. Informative References. . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. Full Copyright Statement. . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introduction</span>
The Open Pluggable Edge Services (OPES) architecture [<a href="#ref-1" title=""An Architecture for Open Pluggable Edge Services (OPES)"">1</a>] enables
cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze, and possibly
transform, application-level messages exchanged between the data
provider and the data consumer.
<span class="grey">Beck, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
The execution of such services is governed by a set of rules
installed on the OPES processor. The enforcement of rules can
trigger the execution of service applications local to the OPES
processor. Alternatively, the OPES processor can distribute the
responsibility of service execution by communicating and
collaborating with one or more remote callout servers. As described
in [<a href="#ref-1" title=""An Architecture for Open Pluggable Edge Services (OPES)"">1</a>], an OPES processor communicates with and invokes services on a
callout server by using a callout protocol. This document presents
the requirements for such a protocol.
The requirements in this document are divided into three categories -
functional requirements, performance requirements, and security
requirements. Each requirement is presented as one or more
statements, followed by brief explanatory material as appropriate.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Functional Requirements</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Reliability</span>
The OPES callout protocol MUST be able to provide ordered reliability
for the communication between an OPES processor and callout server.
Additionally, the callout protocol SHOULD be able to provide
unordered reliability.
In order to satisfy the reliability requirements, the callout
protocol SHOULD specify that it must be used with a transport
protocol that provides ordered/unordered reliability at the
transport-layer, for example TCP [<a href="#ref-6" title=""Transmission Control Protocol"">6</a>] or SCTP [<a href="#ref-7" title=""Stream Control Transmission Protocol"">7</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Congestion Avoidance</span>
The OPES callout protocol MUST ensure that congestion avoidance
matching the standard of <a href="./rfc2914">RFC 2914</a> [<a href="#ref-4" title=""IAB Architectural and Policy Considerations for Open Pluggable Edge Services"">4</a>] is applied on all communication
between the OPES processor and callout server. For this purpose, the
callout protocol SHOULD use a congestion-controlled transport-layer
protocol, presumably either TCP [<a href="#ref-6" title=""Transmission Control Protocol"">6</a>] or SCTP [<a href="#ref-7" title=""Stream Control Transmission Protocol"">7</a>].
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Callout Transactions</span>
The OPES callout protocol MUST enable an OPES processor and a callout
server to perform callout transactions with the purpose of exchanging
partial or complete application-level protocol messages (or
modifications thereof). More specifically, the callout protocol MUST
enable an OPES processor to forward a partial or complete application
message to a callout server so that one or more OPES services can
process the forwarded application message (or parts thereof). The
result of the service operation may be a modified application
message. The callout protocol MUST therefore enable the callout
<span class="grey">Beck, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
server to return a modified application message or the modified parts
of an application message to the OPES processor. Additionally, the
callout protocol MUST enable a callout server to report the result of
a callout transaction (e.g., in the form of a status code) back to
the OPES processor.
A callout transaction is defined as a message exchange between an
OPES processor and a callout server consisting of a callout request
and a callout response. Both, the callout request and the callout
response MAY each consist of one or more callout protocol messages,
i.e. a series of protocol messages. A callout request MUST always
contain a partial or complete application message. A callout
response MUST always indicate the result of the callout transaction.
A callout response MAY contain a modified application message.
Callout transactions are always initiated by a callout request from
an OPES processor and are typically terminated by a callout response
from a callout server. The OPES callout protocol MUST, however, also
provide a mechanism that allows either endpoint of a callout
transaction to terminate a callout transaction before a callout
request or response has been completely received by the corresponding
callout endpoint. Such a mechanism MUST ensure that a premature
termination of a callout transaction does not result in the loss of
application message data.
A premature termination of a callout transaction is required to
support OPES services, which may terminate even before they have
processed the entire application message. Content analysis services,
for example, may be able to classify a Web object after having
processed just the first few bytes of a Web object.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Callout Connections</span>
The OPES callout protocol MUST enable an OPES processor and a callout
server to perform multiple callout transactions over a callout
connection. Additionally, the callout protocol MUST provide a method
of associating callout transactions with callout connections. A
callout connection is defined as a logical connection at the
application-layer between an OPES processor and a callout server. A
callout connection MAY have certain parameters associated with it,
for example parameters that control the fail-over behavior of
connection endpoints. Callout connection-specific parameters MAY be
negotiated between OPES processors and callout servers (see <a href="#section-3.12">Section</a>
<a href="#section-3.12">3.12</a>).
<span class="grey">Beck, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
The OPES callout protocol MAY choose to multiplex multiple callout
connections over a single transport-layer connection if a flow
control mechanism that guarantees fairness among multiplexed callout
connections is applied.
Callout connections MUST always be initiated by an OPES processor. A
callout connection MAY be closed by either endpoint of the
connection, provided that doing so does not affect the normal
operation of on-going callout transactions associated with the
callout connection.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Asynchronous Message Exchange</span>
The OPES callout protocol MUST support an asynchronous message
exchange over callout connections.
In order to allow asynchronous processing on the OPES processor and
callout server, it MUST be possible to separate request issuance from
response processing. The protocol MUST therefore allow multiple
outstanding callout requests and provide a method of correlating
callout responses with callout requests.
Additionally, the callout protocol MUST enable a callout server to
respond to a callout request before it has received the entire
request.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Message Segmentation</span>
The OPES callout protocol MUST allow an OPES processor to forward an
application message to a callout server in a series of smaller
message fragments. The callout protocol MUST further enable the
receiving callout server to re-assemble the fragmented application
message.
Likewise, the callout protocol MUST enable a callout server to return
an application message to an OPES processor in a series of smaller
message fragments. The callout protocol MUST enable the receiving
OPES processor to re-assemble the fragmented application message.
Depending on the application-layer protocol used on the data path,
application messages may be very large in size (for example in the
case of audio/video streams) or of unknown size. In both cases, the
OPES processor has to initiate a callout transaction before it has
received the entire application message to avoid long delays for the
data consumer. The OPES processor MUST therefore be able to forward
fragments or chunks of an application message to a callout server as
<span class="grey">Beck, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
it receives them from the data provider or consumer. Likewise, the
callout server MUST be able to process and return application message
fragments as it receives them from the OPES processor.
Application message segmentation is also required if the OPES callout
protocol provides a flow control mechanism in order to multiplex
multiple callout connections over a single transport-layer connection
(see <a href="#section-3.4">Section 3.4</a>).
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Support for Keep-Alive Mechanism</span>
The OPES callout protocol MUST provide a keep-alive mechanism which,
if used, would allow both endpoints of a callout connection to detect
a failure of the other endpoint, even in the absence of callout
transactions. The callout protocol MAY specify that keep-alive
messages be exchanged over existing callout connections or a separate
connection between OPES processor and callout server. The callout
protocol MAY also specify that the use of the keep-alive mechanism is
optional.
The detection of a callout server failure may enable an OPES
processor to establish a callout connection with a stand-by callout
server so that future callout transactions do not result in the loss
of application message data. The detection of the failure of an OPES
processor may enable a callout server to release resources which
would otherwise not be available for callout transactions with other
OPES processors.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Operation in NAT Environments</span>
The OPES protocol SHOULD be NAT-friendly, i.e., its operation should
not be compromised by the presence of one or more NAT devices in the
path between an OPES processor and a callout server.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. Multiple Callout Servers</span>
The OPES callout protocol MUST allow an OPES processor to
simultaneously communicate with more than one callout server.
In larger networks, OPES services are likely to be hosted by
different callout servers. Therefore, an OPES processor will likely
have to communicate with multiple callout servers. The protocol
design MUST enable an OPES processor to do so.
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>. Multiple OPES Processors</span>
The OPES callout protocol MUST allow a callout server to
simultaneously communicate with more than one OPES processor.
<span class="grey">Beck, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
The protocol design MUST support a scenario in which multiple OPES
processors use the services of a single callout server.
<span class="h3"><a class="selflink" id="section-3.11" href="#section-3.11">3.11</a>. Support for Different Application Protocols</span>
The OPES callout protocol SHOULD be application protocol-agnostic,
i.e., it SHOULD not make any assumptions about the characteristics of
the application-layer protocol used on the data path between the data
provider and data consumer. At a minimum, the callout protocol MUST
be compatible with HTTP [<a href="#ref-5" title=""Hypertext Transfer Protocol -- HTTP/1.1"">5</a>].
The OPES entities on the data path may use different application-
layer protocols, including, but not limited to, HTTP [<a href="#ref-5" title=""Hypertext Transfer Protocol -- HTTP/1.1"">5</a>] and RTP [<a href="#ref-8" title=""RTP: A Transport Protocol for Real-Time Applications"">8</a>].
It would be desirable to be able to use the same OPES callout
protocol for any such application-layer protocol.
<span class="h3"><a class="selflink" id="section-3.12" href="#section-3.12">3.12</a>. Capability and Parameter Negotiations</span>
The OPES callout protocol MUST support the negotiation of
capabilities and callout connection parameters between an OPES
processor and a callout server. This implies that the OPES processor
and the callout server MUST be able to exchange their capabilities
and preferences. Then they MUST be able to engage in a deterministic
negotiation process that terminates either with the two endpoints
agreeing on the capabilities and parameters to be used for future
callout connections/transactions or with a determination that their
capabilities are incompatible.
Capabilities and parameters that could be negotiated between an OPES
processor and a callout server include (but are not limited to):
callout protocol version, fail-over behavior, heartbeat rate for
keep-alive messages, security-related parameters, etc.
The callout protocol MUST NOT use negotiation to determine the
transport protocol to be used for callout connections. The callout
protocol MAY, however, specify that a certain application message
protocol (e.g., HTTP [<a href="#ref-5" title=""Hypertext Transfer Protocol -- HTTP/1.1"">5</a>], RTP [<a href="#ref-8" title=""RTP: A Transport Protocol for Real-Time Applications"">8</a>]) requires the use of a certain
transport protocol (e.g., TCP [<a href="#ref-6" title=""Transmission Control Protocol"">6</a>], SCTP [<a href="#ref-7" title=""Stream Control Transmission Protocol"">7</a>]).
Callout connection parameters may also pertain to the characteristics
of OPES callout services if, for example, callout connections are
associated with one or more specific OPES services. An OPES
service-specific parameter may, for example, specify which parts of
an application message an OPES service requires for its operation.
Callout connection parameters MUST be negotiated on a per-callout
connection basis and before any callout transactions are performed
over the corresponding callout connection. Other parameters and
<span class="grey">Beck, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
capabilities, such as the fail-over behavior, MAY be negotiated
between the two endpoints independently of callout connections.
The parties to a callout protocol MAY use callout connections to
negotiate all or some of their capabilities and parameters.
Alternatively, a separate control connection MAY be used for this
purpose.
<span class="h3"><a class="selflink" id="section-3.13" href="#section-3.13">3.13</a>. Meta Data and Instructions</span>
The OPES callout protocol MUST provide a mechanism for the endpoints
of a particular callout transaction to include metadata and
instructions for the OPES processor or callout server in callout
requests and responses.
Specifically, the callout protocol MUST enable an OPES processor to
include information about the forwarded application message in a
callout request, e.g. in order to specify the type of forwarded
application message or to specify what part(s) of the application
message are forwarded to the callout server. Likewise, the callout
server MUST be able to include information about the returned
application message.
The OPES processor MUST further be able to include an ordered list of
one or more uniquely specified OPES services which are to be
performed on the forwarded application message in the specified
order. However, as the callout protocol MAY also choose to associate
callout connections with specific OPES services, there may not be a
need to identify OPES services on a per-callout transaction basis.
Additionally, the OPES callout protocol MUST allow the callout server
to indicate to the OPES processor the cacheability of callout
responses. This implies that callout responses may have to carry
cache-control instructions for the OPES processor.
The OPES callout protocol MUST further enable the OPES processor to
indicate to the callout server if it has kept a local copy of the
forwarded application message (or parts thereof). This information
enables the callout server to determine whether the forwarded
application message must be returned to the OPES processor, even if
it has not been modified by an OPES service.
The OPES callout protocol MUST also allow OPES processors to comply
with the tracing requirements of the OPES architecture as laid out in
[<a href="#ref-1" title=""An Architecture for Open Pluggable Edge Services (OPES)"">1</a>] and [<a href="#ref-3" title=""IAB Architectural and Policy Considerations for Open Pluggable Edge Services"">3</a>]. This implies that the callout protocol MUST enable a
callout server to convey to the OPES processor information about the
OPES service operations performed on the forwarded application
message.
<span class="grey">Beck, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Performance Requirements</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Protocol Efficiency</span>
The OPES callout protocol SHOULD have minimal latency. For example,
the size and complexity of its headers could be minimized.
Because OPES callout transactions add latency to application protocol
transactions on the data path, callout protocol efficiency is crucial
to overall performance.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Requirements</span>
In the absence of any security mechanisms, sensitive information
might be communicated between the OPES processor and the callout
server in violation of either endpoint's security and privacy policy,
through misconfiguration or deliberate insider attack. By using
strong authentication, message encryption, and integrity checks, this
threat can be minimized to a smaller set of insiders and/or operator
configuration errors.
The OPES processor and the callout servers SHOULD have enforceable
policies that limit the parties they communicate with and that
determine the protections to use based on identities of the endpoints
and other data (such as enduser policies). In order to enforce the
policies, they MUST be able to authenticate the callout protocol
endpoints using cryptographic methods.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Authentication, Confidentiality, and Integrity</span>
The parties to the callout protocol MUST have a sound basis for
binding authenticated identities to the protocol endpoints, and they
MUST verify that these identities are consistent with their security
policies.
The OPES callout protocol MUST provide for message authentication,
confidentiality, and integrity between the OPES processor and the
callout server. It MUST provide mutual authentication. For this
purpose, the callout protocol SHOULD use existing security
mechanisms. The callout protocol specification is not required to
specify the security mechanisms, but it MAY instead refer to a
lower-level security protocol and discuss how its mechanisms are to
be used with the callout protocol.
<span class="grey">Beck, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Hop-by-Hop Confidentiality</span>
If hop-by-hop encryption is a requirement for the content path, then
this confidentiality MUST be extended to the communication between
the OPES processor and the callout server. While it is recommended
that the communication between the OPES processor and callout server
always be encrypted, encryption MAY be optional if both the OPES
processor and the callout server are co-located together in a single
administrative domain with strong confidentiality guarantees.
In order to minimize data exposure, the callout protocol MUST use a
different encryption key for each encrypted content stream.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Operation Across Untrusted Domains</span>
The OPES callout protocol MUST operate securely across untrusted
domains between the OPES processor and the callout server.
If the communication channels between the OPES processor and callout
server cross outside of the organization which is responsible for the
OPES services, then endpoint authentication and message protection
(confidentiality and integrity) MUST be used.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Privacy</span>
Any communication carrying information relevant to privacy policies
MUST protect the data using encryption.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The security requirements for the OPES callout protocol are discussed
in <a href="#section-5">Section 5</a>.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", <a href="./rfc3835">RFC 3835</a>,
August 2004.
[<a id="ref-2">2</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-3">3</a>] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", <a href="./rfc3238">RFC 3238</a>,
January 2002.
<span class="grey">Beck, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
[<a id="ref-4">4</a>] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", <a href="./rfc3238">RFC 3238</a>,
January 2002.
[<a id="ref-5">5</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-6">6</a>] Postel, J., "Transmission Control Protocol", STD 7, <a href="./rfc793">RFC 793</a>,
September 1981.
[<a id="ref-7">7</a>] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", <a href="./rfc2960">RFC 2960</a>, October 2000.
[<a id="ref-8">8</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", <a href="./rfc3550">RFC</a>
<a href="./rfc3550">3550</a>, July 2003.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
Parts of this document are based on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon.
The authors would like to thank the participants of the OPES WG for
their comments on this document.
<span class="grey">Beck, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Authors' Addresses</span>
Andre Beck
Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
US
EMail: abeck@bell-labs.com
Markus Hofmann
Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ 07733
US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman
Purple Streak Development
EMail: ho@alum.mit.edu
URI: <a href="http://www.purplestreak.com">http://www.purplestreak.com</a>
Reinaldo Penno
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
EMail: rpenno@nortelnetworks.com
Andreas Terzis
Computer Science Department
Johns Hopkins University
3400 North Charles Street, 224 NEB
Baltimore, MD 21218
Phone: +1 410 516 5847
EMail: terzis@cs.jhu.edu
<span class="grey">Beck, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3836">RFC 3836</a> Requirements for OPES Callout Protocols August 2004</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Beck, et al. Informational [Page 13]
</pre>
|
