Hi Graham,
a few comments on your text.
A number of attacks can occur if implementations use the HASH and
URL, malicious parties can send a URL to redirect a VPN gateway to a
server which does not contain the HASH of the certificate, but
The server never contains hash, it contains the certificate (or CertBundle)
matching the hash.
instead contains a large file that is then downloaded by the VPN
gateway consuming CPU and memory. For this reason the size of file
pulled by the server SHOULD be limited to a certain value dictated by
the policy for the issuing Certificate Authority. The VPN gateway
I'm not sure if CAs have such a policy (there is a BasicConstraints extension
in certificates, which is relevant, but not the same).
Malicious or mis-configured clients can make numerous requests that
exhaust the HTTP or TCP daemon running on the VPN gateway. The amount
of requests that are performed in a given time should be monitored
and rate limited should HTTP connections fail. The VPN gateway
architecture should be designed so that the repository containing
certificates is on the protected interface of the VPN gateway. This
Sorry, this is impossible (if by "protected interface" you mean
the interface protected by IPsec). That's a chicken-and-egg problem -
you need to get the certificate before the SA is established
(see Section 2 of RFC7296).
Generally speaking, I don't think the attack is so serious.
It is the IKE responder who retrieves data, so it is up to the responder
to decide how much data it retrieves. The malicious http server cannot send
more than one TCP window bytes unless the responder sends next ACK.
And I think that the sane responder would read the first few bytes
and determine the size of the whole ASN structure (certificate or CertBundle),
since all the structures are required to be DER-encoded.
And I agree with you that if the length is suspicious (e.g.
greater than 16 KBs, which is more than enough to hold
four certificates, the number - required to be supported by RFC7296),
then it can just abort the TCP session.
So I don's see it as an amplification attack that Yoav described -
it is not full 4K moovie unless the responder is absolutely careless.
Anyway, isn't the text better be placed in the Security Considerations section?
Regards,
Valery.
Hi
I¹ve updated the draft (attached). Please see section 6.2, where I
describe a method to (potentially) pull your movie in 4k quality..
cheers
On 06/03/2016 17:09, "Yoav Nir" <ynir.i...@gmail.com> wrote:
Sending a request and directing a server to send an entire movie in 4K
quality using RTP in an interesting amplification attack.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
