[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP messages
> From: smb@research.att.com
> I beg your pardon? First you say ``only if you are using the same
> Destination+SPI for more than one socket.'', which is the case for
> host-host keys.
Not in host-host tunnel mode. In that case, there is no socket. As
explained in RFC-1853, soft state needs to be maintained for the tunnel
endpoints to reflect the ICMP messages to the originating host.
This may be that same host, of course, when the tunnel is internally
generated. The same soft state can be reflected to the sockets
individually.
> Then you say ``only a problem for user-user keys'', in
> which case you're less likely to have multiple sockets per SPI. (Though
> it's not impossible, of course.)
>
Some folks have contemplated such. Indeed, your CBC concatenation
attack requires that the same SPI be used by more than one user.
While we probably cannot prohibit this behaviour for manually keyed
implementations, Photuris clearly states that such sharing is not
allowed because it is not secure, and contains mechanisms to prevent
this from happening.
> Scenarios I have in mind are things like ``destination unreachable'', from
> an intermediate router. With a VPN, there will be a lot of sockets
> sharing the same SPI for the firewall-to-firewall key. This is true
> whether key management is manual or automated.
>
The distinction is that the firewalls' tunnel has no sockets itself, and
therefore no need to search the internal headers.
> I confess that I'm surprised by your response, since I seem to remember
> talking about this with you, and you agreeing that this was a problem.
>
I cannot remember the details of our conversation. Perhaps I was
agreeing that it is a problem for users sharing the same host SPI, which
lead to the restriction in Photuris. I do not believe this is a problem
for VPNs following RFC-1853.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: