Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Fri, 18 Mar 2016 22:07:30 +0000

Hi

Updated proposal attached.

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).

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..

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?

cheers

On 16/03/2016 14:21, "IPsec on behalf of Waltermire, David A. (Fed)"
<[email-masked] on behalf of [email-masked]> wrote:

>This is just a friendly reminder that the WGLC on
>draft-ietf-ipsecme-ddos-protection-04.txt ends on March 18th, 2016.
>
>The list discussion has been good on the draft. Thank you to everyone
>that commented so far.
>
>If you have any additional comments, please send them to the list by the
>end of the day UTC on Friday.
>
>Thanks,
>Dave
>
>> -----Original Message-----
>> From: Waltermire, David A. (Fed)
>> Sent: Tuesday, March 01, 2016 10:34 AM
>> To: IPsecME WG <[email-masked]>
>> Subject: WGLC on draft-ietf-ipsecme-ddos-protection-04
>> 
>> All:
>> 
>> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I
>>believe the
>> draft is shaping up nicely, but needs additional review. To that end,
>>this
>> message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-
>> ddos-protection-04.
>> 
>> The version to be reviewed is
>>https://tools.ietf.org/id/draft-ietf-ipsecme-
>> ddos-protection-04.txt.
>> 
>> Please send your comments, questions, and edit proposals to the WG mail
>> list until March 18, 2015.  If you believe that the document is ready
>>to be
>> submitted to the IESG for consideration as a Standards Track RFC please
>>send
>> a short message stating this.
>> 
>> Best Regards,
>> Dave
>
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 20 Mar 2016 09:43:05 +0300

Hi Graham,

thank you for the updated text.

> 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.

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.

> 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.

> 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.

> cheers

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2016 13:20:13 -0400 (EDT)

>>  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.

> See section 1.5 of RFC 7296:

Valery is right.

> 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.

> INITIAL_CONTACT from RFC7296.

Agreed.

> 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

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 20 Mar 2016 21:25:16 +0000

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

>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."

>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.

>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.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2016 17:33:32 -0400

> On Mar 20, 2016, at 17:25, Graham Bartlett (grbartle) <[email-masked]> wrote:
> 
> Hi Valery / Paul
> 

No. Only one message is sent. So no amplification is caused.

> should a received request cause the generation of more than a single

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.

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 20 Mar 2016 21:42:24 +0000

Hi Paul

Fair point - thanks.

cheers

On 20/03/2016 21:33, "Paul Wouters" <[email-masked]> 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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 21 Mar 2016 15:57:28 +0300

Hi Graham,

> should a received request cause the generation of more than a single

Well, I don't think we should describe such obvious things.
And there is already text in RFC 7296 with similar meaning
in section 2.21 (however, without using imperative words):

   There are many kinds of errors that can occur during IKE processing.
   The general rule is that if a request is received that is badly
   formatted, or unacceptable for reasons of policy (such as no matching
   cryptographic algorithms), the response contains a Notify payload
   indicating the error.

(Note singular "the response", not "the responses").

> the mis-configuration and also malicious intent.

I don't think we are in a position to impose such a requirement in the draft.
RFC 7296 doesn't have a requirement that an ID must be present in the
certificate. Moreover, Section 3.5. explicitely allows ID be different
from any field in certfificate:

   The Identification payloads, denoted IDi and IDr in this document,
   allow peers to assert an identity to one another.  This identity may
   be used for policy lookup, but does not necessarily have to match
   anything in the CERT payload; both fields may be used by an
   implementation to perform access control decisions.  When using the
   ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
   does not require this address to match the address in the IP header
   of IKEv2 packets, or anything in the TSi/TSr payloads.  The contents
   of IDi/IDr are used purely to fetch the policy and authentication
   data related to the other party.

There are many good reasons not to to impose such a requirement -
there are many use cases when ID payload just cannot be directly
mapped to credentials (preshared keys, some EAP methods, raw public
keys etc.), so the mapping is performed via Local Policy.
It allows more flexibility in real life, but at the same time it requires
Local Policy to be written with care.

In your example there is a clear configuration error, and I don't think
we could do anything about this on RFC level.
Next time IT engineer issues two certificates with equal FQDNs
to two different people and the situation you described happens again,
even if SGW will check the match betweed ID and certificate...

> intention. The behaviour of INITIAL_CONTACT is really being exploited in

No, I don't think so. To exploit this mis-configuration a malicious user must be
authenticated by SGW. So, he/she is not an unknown attacker, he/she does have
proper credentials. In this case he/she can be traced down
and the out-of-band measures can be taken.

> there’s still cases (and seem to be common) where it can happen.

The draft has a reference to RFC7619. In general, NULL auth is not relevant to DoS protection
unless your product supports it. And in this case you have to read RFC 7619 anyway
while adding support, right?

> adequately mitigate the issue of IP address exhaustion I can add some

Could you please describe how you exhaust the pool of IP addresses?
If you are authenticated user you'll receive the same IP address no matter
how many times you ask for it (in general it depends on SGW implementation,
I assume SGW links client ID with IP from poll).

If you use NULL auth, then it is a different story, but I think
RFC 7619 describes the risks of using NULL auth.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Mar 2016 15:41:55 +0200

> (Note singular "the response", not "the responses").

This is true when sending a response. This is not the case we are
talking about.

This implementation will start completely new INFORMATIONAL exchange
after the IKE_SA_INIT times out. I.e., attacker sends IKE_SA_INIT
request, server responds to this, and then nothing comes through
later. Then the responder will time out the IKE_SA_INIT because it is
half open IKE SA, and starts to do something on it.

In one case we have seen responder initiating completely new
INFORMATIONAL exchange with private error code inside. I.e., this was
not a response, it was new request with new message id etc, and this
request was then retransmitted as RFC7296 specifies for several times,
before it timed out. This exchange was completely in clear as the IKE
SA was not yet finished.

In another case the responder again started new INFORMATIONAL
exchange, but in this the original responder sent encrypted delete
payload for the half open IKE SA, and this message was retransmitted
only once, i.e. only two packets were sent.

The original initiator receiving encrypted and MACed delete
notification for IKE SA it is trying to negotiate (lets say the
IKE_AUTH never reached the responder as they were so big that IP layer
fragmented them and then some network device dropped them) will know
that this is from the node it has talked to in IKE_SA_INIT, so there
is no reason not to act on that delete.

Both of those were using new exchanges, which means they were NOT
against the RFC7296, but especially the first one sending 20+ retries
for the private error notification message was causing amplification
factor. The second case is actually quite good compromize to recover
from cases where some extraordinary case might cause half open IKE SA
to be formed and not causing real amplification for attackers.

Anyways I think the first case is clearly a implementation misfeature,
and they should fix it. The second case is implementation feature,
which might be usable in certain environments. And they might have
rate limiters on it.

> we could do anything about this on RFC level.

Yes. We do not need to try to cover configuration errors and their
effect on DDoS.

> I assume SGW links client ID with IP from poll).

I was about to point exactly that.

> RFC 7619 describes the risks of using NULL auth.

Of course if you are giving address to NULL auth clients then the
situation might be different, but 10.0.0.0/8 network has quite a lot
of addresses you can give out, before you exhaust the pool.
-- 
[email-masked]

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Wed, 23 Mar 2016 19:54:19 +0000

Hi Valery / Tero 

Sorry for the late reply.

GB> Comments inline.

cheers

>I don't think we are in a position to impose such a requirement in the

GB>I feel we should explain WHY it’s a security benefit to link the ID and
certificate. Not to mandate anything. As you said, currently the RFC
states that ID does not have to match certifciate, but I feel this
increases the attack surface for authenticated DoS attacks.

>Local Policy to be written with care.

GB>I’m only proposing this for digital signatures where there is a
cryptographically signed identity in this instance. I’m not suggesting it
should be advised for other ID types (I couldn’t see the benefits).

>>For the malicious example, itвЂ™s easy to spoof an ID, but itвЂ™s

GB>Sure - they can be tracked down, but if we could prevent the
opportunity to perform malicious behaviour surely that would be
beneficial, rather than tracking down someone after the event.

I’ll provide another scenario of malicious intent, where not having a ID
to Cert check increases the attack surface;

A mobile device configured to use certificates is lost and compromised
(private key extracted). If the attacker knows the IKE ID used by all
other members of the Gateway prior to the certificate being revoked the
attacker could authenticate to the Gateway as all other IKE ID's (as the
compromised certificate will pass authentication). In this instance when
INITIAL_CONTACT is used the attacker will be able to delete the legitimate
users active sessions. For VPN Gateways that serve both Remote Access and
Site-to-site VPNs this would have maximum impact, taking out a site-site
connection.

For the case for IoT device it could be weeks before someone realised a
device is compromised, which increases the attack surface even further.

>>thereвЂ™s still cases (and seem to be common) where it can happen.
>
>>authentication. Let me give you this example. IвЂ™m granted access to a
>>VPN
>>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
>>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
>>isnвЂ™t fully trusted, so we should protect the control-plane (IKE) as
>>best
>>we can.
>>
>>wanted to describe the issue and if others feel the text doesnвЂ™t

GB>After a bit more digging, the exploit I thought I had found would
require the implementation to be broken.