1 |
> On 03/09/2013 07:53 AM, Kevin Chadwick wrote: |
2 |
> >> "There is no reason to believe that IPv6 will result in an |
3 |
> >> increased use of IPsec." |
4 |
> >> |
5 |
> >> Bull. The biggest barrier to IPsec use has been NAT! If an |
6 |
> >> intermediate router has to rewrite the packet to change the |
7 |
> >> apparent source and/or destination addresses, then the |
8 |
> >> cryptographic signature will show it, and the packet will be |
9 |
> >> correctly identified as having been tampered with! |
10 |
> >> |
11 |
|
12 |
http://marc.info/?l=openbsd-misc&m=135325641430178&w=2 |
13 |
|
14 |
> > |
15 |
> > It's hardly difficult to get around that now is it. |
16 |
> |
17 |
> Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was |
18 |
> designed from the beginning to allow you to do things like sign your IP |
19 |
> header and encrypt everything else (meaning your UDP, TCP, SCTP or what |
20 |
> have you). |
21 |
> |
22 |
> Setting up a tunnel just so your IP header can be signed wastes another |
23 |
> 40 bytes for every non-fragmented packet. Ask someone trying to use data |
24 |
> in a cellular context how valuable that 40 bytes can be. |
25 |
> |
26 |
> > You are wrong the biggest barrier is that it is not desirable to do |
27 |
> > this as there are many reasons for firewalls to inspect incoming |
28 |
> > packets. I don't agree with things like central virus scanning |
29 |
> > especially by damn ISPs using crappy Huawei hardware, deep inspection |
30 |
> > traffic shaping rather than pure bandwidth usage tracking or active |
31 |
> > IDS myself but I do agree with scrubbing packets. |
32 |
> |
33 |
> It's not the transit network's job to scrub packets. Do your scrubbing |
34 |
> at the VPN endpoint, where the IPSec packets are unwrapped. |
35 |
> |
36 |
> Trusting the transit network to scrub packets is antithetical to the |
37 |
> idea of using security measures to avoid MITM and traffic sniffing |
38 |
> attacks in the first place! |
39 |
> |
40 |
|
41 |
I never said it was. I was more thinking of IPSEC relaying which would |
42 |
be analogous to a VPN end point but without losing the end-end, neither |
43 |
are desirable, NAT has little to do with the lack of IPSEC deployment. |
44 |
|
45 |
What do you gain considering the increased resources, pointlessly |
46 |
increasing chances of cryptanalysis and pointlessly increasing the |
47 |
chances of exploitation due to the fact that the more complex IPSEC |
48 |
itself can have bugs like Openssl does, not to mention amplifying DDOS |
49 |
without the attacker doing anything, which is the biggest and more of a |
50 |
threat than ever, or are you going to stop using the internet. When |
51 |
ipv4 can utilise encryption without limitations including IPSEC but more |
52 |
appropriately like ssh just fine when needed you see it is simply not |
53 |
desirable and a panacea that will not happen. You are simply in a |
54 |
bubble as the IETF were. |
55 |
|
56 |
> > |
57 |
> >> With IPsec, NAT is unnecessary. (You can still use it if you need |
58 |
> >> it...but please try to avoid it!) |
59 |
> >> |
60 |
> > |
61 |
> > Actually it is no problem at all and is far better than some of the |
62 |
> > rubbish ipv6 encourages client apps to do. (See the links I sent in |
63 |
> > the other mail) |
64 |
> |
65 |
> Please read the links before you send them, and make specific references |
66 |
> to the content you want people to look at. I've read and responded to |
67 |
> the links you've offered (which were links to archived messages on |
68 |
> mailing lists, and the messages were opinion pieces with little (if any) |
69 |
> technical material.) |
70 |
> |
71 |
|
72 |
|
73 |
> > |
74 |
> >> Re "DNS support for IPv6" |
75 |
> >> |
76 |
> >> "Increased size of DNS responses due to larger addresses might be |
77 |
> >> exploited for DDos attacks" |
78 |
> >> |
79 |
> >> That's not even significant. Have you looked at the size of DNS |
80 |
> >> responses? The increased size of the address pales in comparison to |
81 |
> >> the amount of other data already stuffed into the packet. |
82 |
> > |
83 |
> > It's been ages since I looked at that link and longer addresses |
84 |
> > would certainly be needed anyway but certainly with DNSSEC again |
85 |
> > concocted by costly unthoughtful and unengaging groups who chose to |
86 |
> > ignore DJB and enable amplification attacks. |
87 |
> |
88 |
> What from DJB did they ignore? I honestly don't know what you're talking |
89 |
> about. |
90 |
> |
91 |
|
92 |
They completely ignored dnscurve.org or that RSA768 was not strong |
93 |
enough to be a good choice and ECDSA should be looked at and most |
94 |
importantly the DOS amplification (we are talking years ago). I even had |
95 |
a discussion with a dns caching tools (that I do like a lot) author who |
96 |
completely dismissed the potential of RSA being broken for years and |
97 |
years. Guess what's come to light since. |
98 |
|
99 |
> > |
100 |
> > His latest on the "DNS security mess" |
101 |
> > |
102 |
> > http://cr.yp.to/talks/2013.02.07/slides.pdf |
103 |
> |
104 |
> I've never before in my life seen someone animate slideshow transitions |
105 |
> and save off intermediate frames as individual PDF pages. That was painful. |
106 |
> |
107 |
|
108 |
Yeah, xpdf worked well though. I actually couldn't find the link |
109 |
and looked it up and thought it was just an update of 2012 as it had |
110 |
the same title and only got around to reading it about an hour later. |
111 |
|
112 |
> So, I read what was discussed there. First, he describes failings of |
113 |
> HTTPSEC. I don't have any problem with what he's talking about there, |
114 |
> honestly; it makes a reasonable amount of sense, considering |
115 |
> intermediate caching servers aren't very common for HTTP traffic, and |
116 |
> HTTPS traffic makes intermediate caching impossible. (unless you've |
117 |
> already got serious security problems by way of a MITM opening.) |
118 |
> |
119 |
> Then he turns around and dedicates two slides showing a DNS delegation |
120 |
> sequence...and then states in a single slide that DNSSEC has all the |
121 |
> same problems as HTTPSEC. |
122 |
> |
123 |
> DNSSEC doesn't have the same problems as HTTPSEC, because almost *every* |
124 |
> recursive resolving DNS server (which is most of the DNS servers on the |
125 |
> Internet) employs caching. |
126 |
> |
127 |
|
128 |
I suggest you read the 2012 slides. |
129 |
|
130 |
> > |
131 |
> >> "An attacker can connect to an IPv4-only network, and forge IPv6 |
132 |
> >> Router Advertisement messages. (*)" |
133 |
> > |
134 |
> >> Again, this depends on them being on the same layer 2 network |
135 |
> >> segment. |
136 |
> > |
137 |
> >> The same class of attacks would be possible for any IPv4 successor |
138 |
> >> that implemented either RAs or DHCP. |
139 |
> > |
140 |
> > Neither of which I use. |
141 |
> |
142 |
> You're telling me you don't use DHCP? Seriously, that you statically |
143 |
> configure the IPv4 addresses of all the hosts on your network? |
144 |
> |
145 |
> With one exception, I haven't personally seen a network configured in |
146 |
> that way since 1998! Certainly, every network has some hosts configured |
147 |
> statically, but virtually no network I've observed (and I've seen |
148 |
> private networks between 2 and 50 hosts, and commercial networks between |
149 |
> 5 and 30k hosts) managed completely statically. |
150 |
> |
151 |
|
152 |
None of my networks for way over a decade have ever employed DHCP and |
153 |
boy am I glad in avoiding many security issues. That was one of the |
154 |
first decisions in network design I made as a teenager. |
155 |
|
156 |
In fact the only networks that do use DHCP by definition are not well |
157 |
cared for such as roaming or tethering a laptop I trust little to my |
158 |
phone which I also trust little and for many good, sorry very bad mobile |
159 |
network reasons. |
160 |
|
161 |
> > |
162 |
> > As I said we would be here all day and that link wasn't as good as |
163 |
> > the one I was actually looking for. |
164 |
> > |
165 |
> > local NAT done right is no problem and actually a good thing and I |
166 |
> > have no issues playing games, running servers or anything else behind |
167 |
> > NAT. |
168 |
> |
169 |
> See others' responses about port standardization, and about how it |
170 |
> enforces a distinction between 'clients' and 'servers' that's |
171 |
> unnecessary (and even harmful) for a variety of applications. |
172 |
> |
173 |
|
174 |
Boy should there be a distinction between clients and servers, without |
175 |
it we would be in a world of pain. However I still atest that there is |
176 |
no problem and far less than what ipv6 advocates. |
177 |
|
178 |
> > Global NAT works well enough |
179 |
> |
180 |
> With global NAT, anything you do that depends on port forwarding is broken. |
181 |
> |
182 |
> > but isn't a good thing and wouldn't exist if they had simply added |
183 |
> > more addresses quickly. The hardware uptake would have been no issue |
184 |
> > rather than a decade of pleads. |
185 |
> |
186 |
> There's almost nothing you've pointed at so far that would have |
187 |
> prevented backbones from IPv6 uptake...and the backbones dragged their |
188 |
> heels long enough. IPv4 with expanded address bits would have been |
189 |
> worse; IPv6 explicitly includes features intended to ease the strain on |
190 |
> the size of a global routing view! |
191 |
> |
192 |
|
193 |
And much more which is the problem and yet still including the bad |
194 |
parts of ipv4 apparently. |
195 |
|
196 |
> > |
197 |
> > We haven't even touched on the code yet and so all the vulnerable |
198 |
> > especially home hardware which yes often has vulnerable sps anyway |
199 |
> > but by no way just home hardware. |
200 |
> > |
201 |
> > The ipvshit links give an insight into the code complexity. |
202 |
> |
203 |
> You call that code complex? (and I still don't know what 'ipvshit' is, |
204 |
> except possibly one guy's pejorative description of IPv6) |
205 |
|
206 |
Think about what it is doing from the comment not the actual code. |
207 |
|
208 |
> |
209 |
> > Note OpenBSDs kernel which is very secure (unlike Linux whose |
210 |
> > primary goal is function) |
211 |
> |
212 |
> I have no complaints about OpenBSD. |
213 |
> |
214 |
> > and has had just a few remote holes in well over a decade, one of |
215 |
> > which was in ipv6 |
216 |
> |
217 |
> So OpenBSD, who you venerate, had a bug in its IPv6 implementation, and |
218 |
> for that you view IPv6 as an abomination? Is that it? (Or is it because |
219 |
> the guy who wrote the buggy code thinks so, and you venerate him? |
220 |
> Because that seems plausible, too.) |
221 |
> |
222 |
|
223 |
You seem to underestimate the gravity or such a bug making it into the |
224 |
OpenBSD kernel. |
225 |
|
226 |
However, not just that, try searching osvdb.org for ipv4 = < 1 page |
227 |
|
228 |
ipv6 = > 3 pages |
229 |
|
230 |
> > and which I had avoided without down time because I won't and what's |
231 |
> > more shouldn't use ipv6 wherever possible |
232 |
> |
233 |
> Do you mean that as "I'll avoid IPv6 as much as possible" or do you mean |
234 |
> that as "I won't use IPv6 in all places where it's possible to use IPv6"? |
235 |
> |
236 |
|
237 |
Former |
238 |
|
239 |
> If the former, I'm afraid I still haven't seen a solid technical case |
240 |
> against it. |
241 |
> |
242 |
|
243 |
|
244 |
> > and had actually removed it from the kernel all together. |
245 |
> |
246 |
> That's sensible; if you're not going to use code, remove it. |
247 |
> |
248 |
|
249 |
You would be surprised, many security books used to say it was a waste |
250 |
of time. I ignored them. |
251 |
|
252 |
> > |
253 |
> > If I am Trolling rather than simply trying to make people aware then |
254 |
> > stating ipv6 is wonderful is Trolling just as much or more. |
255 |
> |
256 |
> IPv6 fixes things about the Internet that are currently broken by IPv4 |
257 |
> address exhaustion. I try to point out where IPv6 fixes things, I try to |
258 |
> clear up popular misconceptions about IPv6, and I try to help people |
259 |
> understand a thing rather than simply fear it. |
260 |
> |
261 |
> If you take a highly competent IPv4 network administrator and drop him |
262 |
> into IPv6 territory without ensuring that he has knowledge of IPv6 best |
263 |
> practices and practical concerns, you're likely to get a broken network |
264 |
> out of it. I try to help keep that from happening. |
265 |
|
266 |
It is more than that. Though I am glad you are reducing the problems out |
267 |
there. IPV6 unarguably is worse than IPV4. You can argue it is also |
268 |
better but where if it is it serves no useful purpose for me that would |
269 |
make me even consider using it unless it is redesigned. |
270 |
|
271 |
|
272 |
-- |
273 |
_______________________________________________________________________ |
274 |
|
275 |
'Write programs that do one thing and do it well. Write programs to work |
276 |
together. Write programs to handle text streams, because that is a |
277 |
universal interface' |
278 |
|
279 |
(Doug McIlroy) |
280 |
_______________________________________________________________________ |