Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
On Sun, 20 Mar 2016, Valery Smyslov wrote: 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). I know all versions of openswan and libreswan upto version 3.15 have that problem. 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: Valery is right. 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). (off-topic: I don't think Linux supports this) I don't think we should repeat all this in the draft. Agreed. Again, I don't think we should copy all the requirements concerning INITIAL_CONTACT from RFC7296. Agreed. 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. That's not entire true for NULL AUTH, but I think those corner cases are discussed in RFC-7619 (null auth) itself and don't need to be repeated here. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
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. GB> I’ve made some comments inline for clarity. cheers On 20/03/2016 06:43, "Valery Smyslov" 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." > >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 co
Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
> On Mar 20, 2016, at 17:25, Graham Bartlett (grbartle) > 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" 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 > I
Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
Hi Paul Fair point - thanks. cheers On 20/03/2016 21:33, "Paul Wouters" wrote: > >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. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
