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
|
Network Working Group S. Bellovin
Request for Comments: 1675 AT&T Bell Laboratories
Category: Informational August 1994
Security Concerns for IPng
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet@munnari.oz.au mailing list.
Overview and Rationale
A number of the candidates for IPng have some features that are
somewhat worrisome from a security perspective. While it is not
necessary that IPng be an improvement over IPv4, it is mandatory that
it not make things worse. Below, I outline a number of areas of
concern. In some cases, there are features that would have a
negative impact on security if nothing else is done. It may be
desirable to adopt the features anyway, but in that case, the
corrective action is mandatory.
Firewalls
For better or worse, firewalls are very much a feature of today's
Internet. They are not, primarily, a response to network protocol
security problems per se. Rather, they are a means to compensate for
failings in software engineering and system administration. As such,
firewalls are not likely to go away any time soon; IPng will do
nothing to make host programs any less buggy. Anything that makes
firewalls harder to deploy will make IPng less acceptable in the
market.
Firewalls impose a number of requirements. First, there must be a
hierarchical address space. Many address-based filters use the
structure of IPv4 addresses for access control decisions.
Fortunately, this is a requirement for scalable routing as well.
Bellovin [Page 1]
^L
RFC 1675 Security Concerns for IPng August 1994
Routers, though, only need access to the destination address of the
packet. Network-level firewalls often need to check both the source
and destination address. A structure that makes it harder to find
the source address is a distinct negative.
There is also a need for access to the transport-level (i.e., the TCP
or UDP) header. This may be for the port number field, or for access
to various flag bits, notably the ACK bit in the TCP header. This
latter field is used to distinguish between incoming and outgoing
calls.
In a different vein, at least one of the possible transition plans
uses network-level packet translators [1]. Organizations that use
firewalls will need to deploy their own translators to aid in
converting their own internal networks. They cannot rely on
centrally-located translators intended to serve the entire Internet
community. It is thus vital that translators be simple, portable to
many common platforms, and cheap -- we do not want to impose too high
a financial barrier for converts to IPng.
By the same token, it is desirable that such translation boxes not be
usable for network-layer connection-laundering. It is difficult
enough to trace back attacks today; we should not make it harder.
(Some brands of terminal servers can be used for laundering. Most
sites with such boxes have learned to configure them so that such
activities are impossible.) Comprehensive logging is a possible
alternative.
IPAE [1] does not have problems with its translation strategy, as
address are (insofar as possible) preserved; it is necessary to avoid
any alternative strategies, such as circuit-level translators, that
might.
Encryption and Authentication
A number of people are starting to experiment with IP-level
encryption and cryptographic authentication. This trend will (and
should) continue. IPng should not make this harder, either
intrinsically or by imposing a substantial perforance barrier.
Encryption can be done with various different granularities: host to
host, host to gateway, and gateway to gateway. All of these have
their uses; IPng must not rule out any of them. Encapsulation and
tunneling strategies are somewhat problematic, as the packet may no
longer carry the original source address when it reaches an
encrypting gateway. (This may be seen more as a constraint on
network topologies. So be it, but we should warn people of the
limitation.)
Bellovin [Page 2]
^L
RFC 1675 Security Concerns for IPng August 1994
Dual-stack approaches, such as in TUBA's transition plan [2], imply
multiple addresses for each host. (IPAE has this feature, too.) The
encryption and access control infrastructure needs to know about all
addresses for a given host, belonging to whichever stack. It should
not be possible to bypass authentication or encryption by asking for
a different address for the same host.
Source Routing and Address-based Authentication
The dominant form of host authentication in today's Internet is
address-based. That is, hosts often decide to trust other hosts
based on their IP addresses. (Actually, it's worse than that; much
authentication is name-based, which opens up new avenues of attack.
But if an attacker can spoof an IP address, there's no need to attack
the name service.) To the extent that it does work, address-based
authentication relies on the implied accuracy of the return route.
That is, though it is easy to inject packets with a false source
address, replies will generally follow the usual routing patterns,
and be sent to the real host with that address. This frustrates
most, though not all, attempts at impersonation.
Problems can arise if source-routing is used. A source route, which
must be reversed for reply packets, overrides the usual routing
mechanism, and hence destroys the security of address-based
authentication. For this reason, many organizations disable source-
routing, at least at their border routers.
One candidate IPng -- SIPP -- includes source-routing as an important
component. To the extent this is used, it is a breaks address-based
authentication. This may not be bad; in fact, it is probably good.
But it is vital that a more secure cryptographic authentication
protocol be defined and deployed before any substantial cutover to
source routing, if SIPP is adopted.
Accounting
An significant part of the world wishes to do usage-sensitive
accounting. This may be for billing, or it may simply be to
accomodate quality-of-service requests. Either way, definitive
knowledge of the relevant address fields is needed. To accomodate
this, IPng should have a non-intrusive packet authentication
mechanism. By "non-intrusive", I mean that it should (a) present
little or no load to intermediate hops that do not need to do
authentication; (b) be deletable (if desired) by the border gateways,
and (c) be ignorable by end-systems or billing systems to which it is
not relevant.
Bellovin [Page 3]
^L
RFC 1675 Security Concerns for IPng August 1994
References
[1] Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability
and Transition Mechanism", Work in Progress, March 16, 1994.
[2] Piscitello, D., "Transition Plan for TUBA/CLNP", Work in
Progress, March 4, 1994.
Security Consierations
This entire memo is about Security Considerations.
Author's Address
Steven M. Bellovin
Software Engineering Research Department
AT&T Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ 07974, USA
Phone: +1 908-582-5886
Fax: +1 908-582-3063
EMail: smb@research.att.com
Bellovin [Page 4]
^L
|
