-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-martinsen-tram-dscp-mangle-detection.xml
279 lines (254 loc) · 9.83 KB
/
draft-martinsen-tram-dscp-mangle-detection.xml
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
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-martinsen-tram-dscp-mangle-detection-latest"
ipr="trust200902">
<front>
<title abbrev="DSCP mangle detection">DSCP mangle detection</title>
<author fullname="Paal-Erik Martinsen" initials="P.E" surname="Martinsen">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Philip Pedersens vei 22</street>
<city>Lysaker</city>
<region>Akershus</region>
<code>1325</code>
<country>Norway</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Colin Perkins" initials="C. S." surname="Perkins">
<organization>University of Glasgow</organization>
<address>
<postal>
<street>School of Computing Science</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<workgroup>TRAM</workgroup>
<abstract>
<t>
This document describes a mechanism for an endpoint to
detect DSCP "mangling" by the network path.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>
In some use-cases is useful to know if the network path changes
the DSCP/TOS values in the IP header.
</t>
<t>
This document introduces a new STUN attribute that can carry
the original DSCP/TOS values. This enables the remote receiver
to compare the values in the IP header and the STUN attribute
to detect mangling.
</t>
<t>
The information in the STUN attribute is probably of little
interest for the remote receiver. The main use case is to
collect metrics regarding how often DSCP values are mangled.
</t>
<t>
ICE could potentially also use this information to prefer
paths with intact DSCP markings.
</t>
<t>
(Just assigning an attribute from IANA is possible, but we
thought it was better to have a draft describing the attribute
so everyone knows what it is)
</t>
</section>
<section anchor="notation" title="Notational Conventions">
<t>
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 <xref target="RFC2119"></xref>.
</t>
<t>
This specification uses terminology defined in <xref
target="RFC5245">ICE</xref> And STUN <xref
target="RFC5389"></xref>.
</t>
</section>
<section anchor="alg_over"
title="Detecting DSCP mangling">
<t>
Both ICE <xref target="RFC5245">ICE</xref> connectivity checks
and TURN <xref target="RFC5766">ICE</xref> allocations can
benefit from detecting if the DSCP bits survives the rough
journey across the Internet ocean.
</t>
<t>
RFC 6679 "Explicit Congestion Notification (ECN) for RTP over
UDP" <xref target="RFC6679"></xref> section 7.2.2 covers a
subset of the functionality defined in this draft. It covers
cases where the users only are interested in the ECN bits.
</t>
<section anchor="new_attribute"
title="DSCP VALUE attribute">
<t>
The IANA assigned STUN type for the new attribute is TBD-CA.
</t>
<t>
The format of the value in DSCP_VALUE
attribute in the request is:
</t>
<t>
<figure anchor="Figure1"
title="DSCP_VALUE attribute ">
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx DSCP |TxE| Rx DSCP |RxE| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The fields is described below:
</t>
<t>
<list style="hanging">
<t hangText="Tx DSCP:">The DSCP field value if the
IP header carrying the transmitted STUN packet.
</t>
<t hangText="TxE"> The ECT field of the IP header carrying
the transmitted STUN packet.
</t>
<t hangText="Rx DSCP value:">The DSCP field value of the
IP header in the received STUN packet on the same 5-tuple.
</t>
<t hangText="RxE"> The ECT field value of the IP header in
the received STUN packet on the same 5-tuple.
</t>
</list>
</t>
<t>
The padding is necessary to hit the 32-bit boundary needed
for STUN attributes. The padding bits are ignored, but to
allow for future reuse of these bits they MUST be set to 0.
</t>
</section>
<section title="Usage in Requests">
<t>
When sending a STUN request in sets the Tx DSCP value field
to the same value as the DSCP/TOS field in the IP header of
the packet that is going to carry the STUN request. The Rx
DSCP value MUST be set to 0.
</t>
</section>
<section title="Usage in Responses">
<t>
This attribute MUST only be added to the response if it was
present in the request.
</t>
<t>
The Tx DSCP value field is populated with the value of the
DSCP/TOS field of the IP packet carrying the STUN
response. the Rx DSCP value is populated with the value from
the DSCP/TOS field from the packet carrying the original
receiving STUN request.
</t>
</section>
<section anchor="example_operation" title="Example Operation">
<t>
When a client receives the response it can compare the
values of in the DSCP_VALUE attribute with values from the
IP socket. The results could be used to detect and collect
metrics regarding DSCP "survivability" on the Internet. It
could potentially also influence ICE path decisions.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>[Paragraphs in braces should be removed by the RFC Editor
upon publication]</t>
<t>[The TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA
allocate a value in the "STUN attributes Registry" from the
comprehension-optional range (0x8000-0xBFFF), to be replaced for
TBD-CA throughout this document]</t>
<t>This document defines the DSCP_VALUE STUN attribute,
described in <xref target="alg_over"></xref>. IANA has allocated
the comprehension-optional code-point TBD-CA for this
attribute.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Security considerations discussed in <xref
target="RFC5389"></xref> are to be taken into account. STUN
requires the 96 bits transaction ID to be uniformly and
randomly chosen from the interval 0 .. 2**96-1, and be
cryptographically strong. This is good enough security against
an off-path attacker. An on-path attacker can either inject a
fake response or modify the values in
DSCP_VALUE attribute to mislead the client
and server. This attack can be mitigated using STUN
authentication. As DSCP_VALUE is expected to
be used between peers using ICE, and ICE uses STUN short-term
credential mechanism the risk of on-path attack influencing
the messages is minimal. If DSCP_VALUE is
used with Allocate request then STUN long-term credential
mechanism or STUN Extension for Third-Party Authorization
<xref target="RFC7635"></xref> or (D)TLS connection can be
used between the TURN client and the TURN server to prevent
attackers from trying to impersonate a TURN server and sending
bogus DSCP_VALUE attribute in the Allocate
response.
</t>
<t>
The information sent in any STUN packet if not encrypted can
potentially be observed passively and used for reconnaissance
and later attacks.
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>
Someone that provided feedback?
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.5766" ?>
<?rfc include="reference.RFC.6679" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7635" ?>
</references>
</back>
</rfc>