> On Mar 20, 2016, at 17:25, Graham Bartlett (grbartle) <grbar...@cisco.com> > wrote: > > Hi Valery / Paul > > Paul - does your implementation send the INFORMATIONAL + other messages > (Private Use Error) to a single SA_INIT? Just to clarify the issue > observed seemed to be SA_INIT is sent by Initiator, Responder sends an > SA_INIT reply plus numerous INFORMATIONAL messages separately to this > single SA_INIT message containing Private Use Errors.
No. Only one message is sent. So no amplification is caused. > > GB> I’ve made some comments inline for clarity. > > cheers > >> On 20/03/2016 06:43, "Valery Smyslov" <sva...@gmail.com> wrote: >> >> Hi Graham, >> >> thank you for the updated text. >> >>> I¹ve made some amendments to the proposed text based on Valerys >>> comments. >>> >>> I¹ve also added text around the correct sending of INFORMATIONAL >>> messages >>> due to a Responder receiving an SA_INIT, this is a known problem today >>> with a number of implementations. (seen by Tero and myself). >> >> Sorry, your text is wrong (or at least is not accurate). The responder >> must never reply to an IKE_SA_INIT with INFORMATIONAL message. >> See section 1.5 of RFC 7296: >> >> In the second and third cases, the message is always sent without >> cryptographic protection (outside of an IKE SA), and includes either >> an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no >> notification data). The message is a response message, and thus it >> is sent to the IP address and port from whence it came with the same >> IKE SPIs and the Message ID and Exchange Type are copied from the >> request. The Response flag is set to 1, and the version flags are >> set in the normal fashion. >> >> Note, thet Exchange Type is copied from the request, so if some >> IKE_SA_INIT >> request has unsupported major version the responder will send >> INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response. > > GB> Thanks Valery - this is now clear. However not only was I confused, as > Paul confirms there’s other implementations that are also confused. Seeing > as there’s confusion with regards to this wording and it can lead to an > amplification attack I personally feel we should include the following > text for clarification? > > "RFC7296 Section 1.5 describes the generating of informational messages a > Responder will send. Only a single instance of the generated message > should ever be sent for a received request and under no circumstances > should a received request cause the generation of more than a single > message in reply." I don't think mitigation text for blatant RFC errors should be added. The original error should just be fixed. If they don't comply with 7296, this document will make no difference either. > > > > > >> >> The only case unprotected INFORMATIONAL message is sent is when >> the host receives AH/ESP packet with unknown SPI. And all these cases >> are covered in Section 1.5 of RFC 7296 in sufficient detail, including >> DoS attacks prevention measures (rate limiting). >> I don't think we should repeat all this in the draft. >> >>> I have also moved text to section 11. Security Consideration. >>> >>> I¹ve added some words around the checking of the IDi/IDr. I¹ve >>> personally >>> seen some issues when misconfigured clients have presented an identical >>> IDi, resulting in INITIAL_CONTACT deleting the Œother¹ clients SA. >> >> Since INITIAL_CONTACT is processed after peer authentication, >> malicious user cannot use it to perform DoS attack >> (unless he/she is able to impersonate legitimate user, but in this case >> he/she can do much worse things). And what about misconfiguration - >> Section 2.4 of RFC 7296 already has all due warnings: >> >> This notification MUST NOT be sent by an entity that may be >> replicated (e.g., a roaming user's credentials where the user is >> allowed to connect to the corporate firewall from two remote systems >> at the same time). >> >> Again, I don't think we should copy all the requirements concerning >> INITIAL_CONTACT from RFC7296. > > > > GB> For this example I’ve personally seen misconfigured clients, this > isn’t exactly the 'entity being replicated' (or not intentionally). As an > example VPN architecture, the authentication use Digital Signatures, but > send the ID as FQDN. Your laptop is provisioned with ID of > FQDN=valery.example.com, mine should be FQDN=graham.example.com, however > due to an IT engineer provision error I have the same ID as you in my VPN > profile. When I connect, if the VPN gateway does not check the presented > FQDN is in the certificate (where a mismatch would occur), I pass > authentication and INITIAL_CONTACT deletes your session. The strict check > of ensuring that the ID is contained within the certificate will mitigate > the mis-configuration and also malicious intent. > > For the malicious example, it’s easy to spoof an ID, but it’s > computationally impossible to spoof a certificate, hence the > ID-Certificate check will mitigate any mis-conftguation or malicious > intention. The behaviour of INITIAL_CONTACT is really being exploited in > this case (IMO). > > > > GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, > not just RFC7619, so if someone is looking to protect RFC7296 against > DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but > there’s still cases (and seem to be common) where it can happen. > > > >> >>> I did think about exhaustion of IP addresses when using configuration >>> payload to allocate clients IPs, if a malicious or misconfigured client >>> could exhaust the pool. But I feel the wording in section 8 covers this. >>> Unless others think otherwise? >> >> Again, allocation of IP addresses takes place after user authentication, >> so it cannot be used as DoS attack by malicious user. > > GB> Think of mischievous users or misconfigured, as anyone who CAN pass > authentication. Let me give you this example. I’m granted access to a VPN > gateway for 24 hours, where a security policy is applied so that I only > access read access to a single file. I’m an ‘untrusted’ user, this gateway > also serves ’trusted’ users. I am granted very limited access. I exhaust > the pool of IP addresses so that no other (legitimate) users can connect. > This is similar to DHCP exhaustion on a LAN. We can mitigate against that > (DHCP snooping etc), I feel that we should protect IKE from a similar > attack. > > GB> I’m seeing a lot of cases (IoT), where IKE is used, however the > devices aren’t secured and are not really trusted. Examples are; Sensor on > a pole in the middle of no-where, or unsecured in a lift shaft. For the > IoT case although the authentication exchange passes, the client still > isn’t fully trusted, so we should protect the control-plane (IKE) as best > we can. > > GB> FWIW - I feel that the text in section 8 does sort of cover this, but > wanted to describe the issue and if others feel the text doesn’t > adequately mitigate the issue of IP address exhaustion I can add some > words. > > >>> cheers >> >> Regards, >> Valery. >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
