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

[Tero Kivinen]

Valery Smyslov writes:
> 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").

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.

> In your example there is a clear configuration error, and I don't think
> 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.

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

I was about to point exactly that.

> If you use NULL auth, then it is a different story, but I think
> 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.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Graham,


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


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


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


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


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


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.


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.


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?


>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 

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

[Graham Bartlett (grbartle)]

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

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

[Paul Wouters]

> 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 

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

[Graham Bartlett (grbartle)]

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 

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

[Paul Wouters]

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

[Valery Smyslov]

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.

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.


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.


cheers


Regards,
Valery. 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Graham Bartlett (grbartle) writes:
> There’s many references to IKEv2 in the paper. E.g.

There is references to the IKEv2, but the paper is not talking about
the IKEv2. It is clear from the packet traces (see version number),
and the retransmission behavior seen.

In the IKEv2 the responder will NEVER retransmit the response unless
initiator retransmits its request (provided the implementation folows
what RFC mandates). 

> "Figure 1: Zmap scan using our IKEv2 payload”..
> 
> I’ve managed to track the author down and made contact. I’ll sync you in
> on a mail and hopefully we can verify what was exactly was used.
> 
> All I would ask is - if many IKEv2 implementation are vulnerable to an
> amplification attack, I feel it would be prudent to add some words to
> remind implementors of the risk.

I do not know any IKEv2 implementations that would be vulnerable to
this multiple responses attack, and if IKEv2 is implemented as
specified in the RFC7296, they are not vulnerable.

>From RFC7296:

   For every pair of IKE messages, the initiator is responsible for
   retransmission in the event of a timeout. The responder MUST never
   retransmit a response unless it receives a retransmission of the
   request. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Wed, 16 Mar 2016, Yoav Nir wrote:


Really?  Granted, it’s been a couple of years since I’ve checked the VPN 
capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and 
XAuth (A Cisco extension to IKEv1). We have some people from Apple in the 
working group who are talking about IKEv2 on the phone, but I don’t think 
they’re removing the support for L2TP or XAuth.


Apple is pretty aggressively pushing IKEv2 (Thanks Tommy!)


Android IIRC also has the L2TP with IKEv1. Not sure what else.

Windows Mobile?  You can add your own, or you have the usual Windows PPTP, L2TP 
(again with IKEv1) and IKEv2.

Who’s killing IKEv1?


What I meant was in the last two years, the switch has been to have
IKEv2 be the "current default VPN" and IKEv1 be the "legacy VPN".

Note Windows Mobile did not have PPTP or L2TP until a few months ago,
when they re-added it :(

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

> 
> Or perhaps we need the IKEv1 considered harmful draft /
> ikev1-diediediediedie... 

I don't think that will help. I've seen how reluctant people are to change 
their 10 year old working VPN. 

IKEv1 is dying pretty quickly now, thanks to mobile phones. But it will be 
another year or two. Right now,
a diediedie document won't help me remove or disable IKEv1 code.

> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Michael Richardson]

Tero Kivinen  wrote:
> What we could say in the DDoS draft is to add saying that IKEv1
> protocol is obsoleted, and will be common avenue for the DDoS attacks,
> and because of that it MUST be disabled.

> Or perhaps we need the IKEv1 considered harmful draft /
> ikev1-diediediediedie...

Yes, I would say so.

I'd even suggest that maybe it needs a CVE against products that have IKEv1
turned on by default.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

These are all backwards compatible things. The cool things are happening at 
IKEv2, and the management tools and required features will push users to v2. 
Sure static v1 site to site will remain in place until 3des or hmac-md5 is 
broken (and they'd still not upgrade)

Just make sure people don't implement support for tcp in v1 :)

Sent from my iPhone

> On Mar 16, 2016, at 08:39, Yoav Nir  wrote:
> 
> 
>> On 16 Mar 2016, at 2:27 PM, Paul Wouters  wrote:
>> 
>> 
>>> 
>>> Or perhaps we need the IKEv1 considered harmful draft /
>>> ikev1-diediediediedie...
>> 
>> I don't think that will help. I've seen how reluctant people are to change 
>> their 10 year old working VPN. 
>> 
>> IKEv1 is dying pretty quickly now, thanks to mobile phones.
> 
> Really?  Granted, it’s been a couple of years since I’ve checked the VPN 
> capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and 
> XAuth (A Cisco extension to IKEv1). We have some people from Apple in the 
> working group who are talking about IKEv2 on the phone, but I don’t think 
> they’re removing the support for L2TP or XAuth.
> 
> Android IIRC also has the L2TP with IKEv1. Not sure what else.
> 
> Windows Mobile?  You can add your own, or you have the usual Windows PPTP, 
> L2TP (again with IKEv1) and IKEv2.
> 
> Who’s killing IKEv1?
> 
> Yoav
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Waltermire, David A. (Fed)]

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 
> 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Graham Bartlett (grbartle)]

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)"
 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 
>> 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
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

 



IPSecME Working Group Y. Nir
Internet-Draft   Check Point
Intended status: Standards Track  V. Smyslov
Expires: September 9, 2016ELVIS-PLUS
  G.Bartlett
   Cisco Systems
   March 8, 2016


  Protecting Internet Key Exchange Protocol version 2 (IKEv2)
   Implementations from Distributed Denial of Service Attacks
 draft-ietf-ipsecme-ddos-protection-05

Abstract

   This document recommends implementation and configuration best
   practices for Internet Key Exchange Protocol version 2 (IKEv2)
   Responders, to allow them to resist Denial of Service and Distributed
   Denial of Service attacks.  Additionally, the document introduces a
   new mechanism called "Client Puzzles" that help accomplish this task.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
 


Nir & Smyslov & BartlettExpires September 9, 2016   [Page 1]

Internet-Draft DDoS Protection for IKEv2  March 2016


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of














































 


Nir & Smyslov & BartlettExpires September 9, 2016   

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

[Yoav Nir]

> On 16 Mar 2016, at 2:27 PM, Paul Wouters  wrote:
> 
> 
>> 
>> Or perhaps we need the IKEv1 considered harmful draft /
>> ikev1-diediediediedie... 
> 
> I don't think that will help. I've seen how reluctant people are to change 
> their 10 year old working VPN. 
> 
> IKEv1 is dying pretty quickly now, thanks to mobile phones.

Really?  Granted, it’s been a couple of years since I’ve checked the VPN 
capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and 
XAuth (A Cisco extension to IKEv1). We have some people from Apple in the 
working group who are talking about IKEv2 on the phone, but I don’t think 
they’re removing the support for L2TP or XAuth.

Android IIRC also has the L2TP with IKEv1. Not sure what else.

Windows Mobile?  You can add your own, or you have the usual Windows PPTP, L2TP 
(again with IKEv1) and IKEv2.

Who’s killing IKEv1?

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Graham Bartlett (grbartle)]

Hi Tero

There’s many references to IKEv2 in the paper. E.g.

"Figure 1: Zmap scan using our IKEv2 payload”..

I’ve managed to track the author down and made contact. I’ll sync you in
on a mail and hopefully we can verify what was exactly was used.

All I would ask is - if many IKEv2 implementation are vulnerable to an
amplification attack, I feel it would be prudent to add some words to
remind implementors of the risk.





cheers


On 16/03/2016 00:51, "Tero Kivinen"  wrote:

>Graham Bartlett (grbartle) writes:
>> Hi
>> 
>> Last night I noticed the following,
>> 
>> https://community.akamai.com/docs/DOC-5289
>> 
>> It talks of various results when using a single packet to generate an
>> amplification attack. (well worth a read..)
>
>And it does NOT talk about IKEv2 at all. The whole text is only
>covering IKEv1, even if they claim to cover both IKE and IKEv2.
>
>RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
>IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
>completely different transmission policy, i.e. it does not use what is
>defined in the RFC2408.
>
>This paper is just completely wrong and the conclusions for it is also
>completely wrong for IKEv2.
>
>It should really say that everybody simply should DISABLE IKEv1 and
>only enable IKEv2 in their configuration and that should fix the issue.
>
>The paper does not even have any kind of contact information, so there
>is no way to send in comments to try to get them to understand that
>their paper is completely wrong when related to the IKEv2.
>
>> As we discussed last week, all implementations that send multiple
>>replies
>> to a single SA_INIT would be broken in some form. Because of the impact
>>of
>> this (and these shocking results), I¹d like to add the following words
>>to
>> the security considerations around retransmissions with respect to
>> amplification attacks using SA_INIT / IKE_AUTH;
>
>In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
>sent. All the frames used Exchange Type of 2 (Identity Protect ==
>IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
>etc). 
>
>> "As described in RFC7296 Use of Retransmission Timers. For every pair of
>> message it is the responsibility of the initiator to retransmit should a
>> message be lost. A responder MUST only send a single reply to an SA_INIT
>> or IKE_AUTH message and MUST never engage the retransmission mechanism,
>> even if a reply is not received. This mitigates the chances that a
>> response will become a victim of an amplification attack where a single
>> packet is used to generate multiple replies."
>
>This requirement is already in the RFC7296 section 2.1, and there is
>no point of say it again here. Even if we say it here, it does not
>change the retransmissions for the IKEv1, as this draft does not cover
>IKEv1.
>
>What we could say in the DDoS draft is to add saying that IKEv1
>protocol is obsoleted, and will be common avenue for the DDoS attacks,
>and because of that it MUST be disabled.
>
>Or perhaps we need the IKEv1 considered harmful draft /
>ikev1-diediediediedie...
>-- 
>kivi...@iki.fi


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Dr. Karan Verma]

yes, it's right

+1

On Wed, Mar 16, 2016 at 6:21 AM, Tero Kivinen  wrote:

> Graham Bartlett (grbartle) writes:
> > Hi
> >
> > Last night I noticed the following,
> >
> > https://community.akamai.com/docs/DOC-5289
> >
> > It talks of various results when using a single packet to generate an
> > amplification attack. (well worth a read..)
>
> And it does NOT talk about IKEv2 at all. The whole text is only
> covering IKEv1, even if they claim to cover both IKE and IKEv2.
>
> RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
> IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
> completely different transmission policy, i.e. it does not use what is
> defined in the RFC2408.
>
> This paper is just completely wrong and the conclusions for it is also
> completely wrong for IKEv2.
>
> It should really say that everybody simply should DISABLE IKEv1 and
> only enable IKEv2 in their configuration and that should fix the issue.
>
> The paper does not even have any kind of contact information, so there
> is no way to send in comments to try to get them to understand that
> their paper is completely wrong when related to the IKEv2.
>
> > As we discussed last week, all implementations that send multiple replies
> > to a single SA_INIT would be broken in some form. Because of the impact
> of
> > this (and these shocking results), I¹d like to add the following words to
> > the security considerations around retransmissions with respect to
> > amplification attacks using SA_INIT / IKE_AUTH;
>
> In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
> sent. All the frames used Exchange Type of 2 (Identity Protect ==
> IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
> etc).
>
> > "As described in RFC7296 Use of Retransmission Timers. For every pair of
> > message it is the responsibility of the initiator to retransmit should a
> > message be lost. A responder MUST only send a single reply to an SA_INIT
> > or IKE_AUTH message and MUST never engage the retransmission mechanism,
> > even if a reply is not received. This mitigates the chances that a
> > response will become a victim of an amplification attack where a single
> > packet is used to generate multiple replies."
>
> This requirement is already in the RFC7296 section 2.1, and there is
> no point of say it again here. Even if we say it here, it does not
> change the retransmissions for the IKEv1, as this draft does not cover
> IKEv1.
>
> What we could say in the DDoS draft is to add saying that IKEv1
> protocol is obsoleted, and will be common avenue for the DDoS attacks,
> and because of that it MUST be disabled.
>
> Or perhaps we need the IKEv1 considered harmful draft /
> ikev1-diediediediedie...
> --
> kivi...@iki.fi
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Best Regards

Dr. Karan Verma
Assistant Professor
Computer Science and Engineering Dept.
Central University Rajasthan, India
Website: www.drkaranverma.com
Phone: +917568169258
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Graham Bartlett (grbartle) writes:
> Hi
> 
> Last night I noticed the following,
> 
> https://community.akamai.com/docs/DOC-5289
> 
> It talks of various results when using a single packet to generate an
> amplification attack. (well worth a read..)

And it does NOT talk about IKEv2 at all. The whole text is only
covering IKEv1, even if they claim to cover both IKE and IKEv2.

RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
completely different transmission policy, i.e. it does not use what is
defined in the RFC2408.

This paper is just completely wrong and the conclusions for it is also
completely wrong for IKEv2.

It should really say that everybody simply should DISABLE IKEv1 and
only enable IKEv2 in their configuration and that should fix the issue.

The paper does not even have any kind of contact information, so there
is no way to send in comments to try to get them to understand that
their paper is completely wrong when related to the IKEv2.

> As we discussed last week, all implementations that send multiple replies
> to a single SA_INIT would be broken in some form. Because of the impact of
> this (and these shocking results), I¹d like to add the following words to
> the security considerations around retransmissions with respect to
> amplification attacks using SA_INIT / IKE_AUTH;

In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
sent. All the frames used Exchange Type of 2 (Identity Protect ==
IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
etc). 

> "As described in RFC7296 Use of Retransmission Timers. For every pair of
> message it is the responsibility of the initiator to retransmit should a
> message be lost. A responder MUST only send a single reply to an SA_INIT
> or IKE_AUTH message and MUST never engage the retransmission mechanism,
> even if a reply is not received. This mitigates the chances that a
> response will become a victim of an amplification attack where a single
> packet is used to generate multiple replies."

This requirement is already in the RFC7296 section 2.1, and there is
no point of say it again here. Even if we say it here, it does not
change the retransmissions for the IKEv1, as this draft does not cover
IKEv1.

What we could say in the DDoS draft is to add saying that IKEv1
protocol is obsoleted, and will be common avenue for the DDoS attacks,
and because of that it MUST be disabled.

Or perhaps we need the IKEv1 considered harmful draft /
ikev1-diediediediedie... 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Graham,

I don't think it is necessary, since RFC7296 already has
the requirement in Section 2.1:

  For every pair of IKE messages, the initiator is responsible for
  retransmission in the event of a timeout.  The responder MUST never
  retransmit a response unless it receives a retransmission of the
  request.

So, such implementations are obviously broken, and I don't
think we need to duplicate the RFC2119 requirements from IKEv2 spec.
If you think it's worth to emphasize this requirement, then, I think,
it  must be re-worded without using RFC2119 words,
and must refer to the RFC7296 as the source of requirement.
Something like that:

   To prevent amplification attacks the Responder must
   retransmit the response message only if it receives a
   retransmitted request from Initiator, and must not do it
   under any other circumstances. Note, that this behaviour
   is already prescribed in Section 2.1 of RFC7296.

Regards,
Valery.

- Original Message - 
From: "Graham Bartlett (grbartle)" <grbar...@cisco.com>

To: "Yoav Nir" <ynir.i...@gmail.com>
Cc: "Valery Smyslov" <sva...@gmail.com>; "Paul Wouters" <p...@nohats.ca>; 
<ipsec@ietf.org>
Sent: Tuesday, March 15, 2016 6:25 PM
Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04


Hi

Last night I noticed the following,

https://community.akamai.com/docs/DOC-5289

It talks of various results when using a single packet to generate an
amplification attack. (well worth a read..)

As we discussed last week, all implementations that send multiple replies
to a single SA_INIT would be broken in some form. Because of the impact of
this (and these shocking results), I№d like to add the following words to
the security considerations around retransmissions with respect to
amplification attacks using SA_INIT / IKE_AUTH;

"As described in RFC7296 Use of Retransmission Timers. For every pair of
message it is the responsibility of the initiator to retransmit should a
message be lost. A responder MUST only send a single reply to an SA_INIT
or IKE_AUTH message and MUST never engage the retransmission mechanism,
even if a reply is not received. This mitigates the chances that a
response will become a victim of an amplification attack where a single
packet is used to generate multiple replies."

Thoughts?

cheers







On 06/03/2016 17:09, "Yoav Nir" <ynir.i...@gmail.com> wrote:


IMHO even in that case this is not an interesting attack. We should be
worried about amplification attacks where little traffic causes a lot of
traffic, not a case where I send a 200-byte packet which results in a
250-byte packet, and not even a 5 250-byte packets. Sending a request and
directing a server to send an entire movie in 4K quality using RTP in an
interesting amplification attack. Using a 10-Mbps uplink to generate
12-Mbps of traffic is not.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Graham Bartlett (grbartle)]

Hi

Last night I noticed the following,

https://community.akamai.com/docs/DOC-5289

It talks of various results when using a single packet to generate an
amplification attack. (well worth a read..)

As we discussed last week, all implementations that send multiple replies
to a single SA_INIT would be broken in some form. Because of the impact of
this (and these shocking results), I¹d like to add the following words to
the security considerations around retransmissions with respect to
amplification attacks using SA_INIT / IKE_AUTH;

"As described in RFC7296 Use of Retransmission Timers. For every pair of
message it is the responsibility of the initiator to retransmit should a
message be lost. A responder MUST only send a single reply to an SA_INIT
or IKE_AUTH message and MUST never engage the retransmission mechanism,
even if a reply is not received. This mitigates the chances that a
response will become a victim of an amplification attack where a single
packet is used to generate multiple replies."

Thoughts?

cheers







On 06/03/2016 17:09, "Yoav Nir"  wrote:

>IMHO even in that case this is not an interesting attack. We should be
>worried about amplification attacks where little traffic causes a lot of
>traffic, not a case where I send a 200-byte packet which results in a
>250-byte packet, and not even a 5 250-byte packets. Sending a request and
>directing a server to send an entire movie in 4K quality using RTP in an
>interesting amplification attack. Using a 10-Mbps uplink to generate
>12-Mbps of traffic is not.
>
>Yoav


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Graham Bartlett (grbartle)]

(Resending as my 1st attempt didn’t seem to make it to the list..)

Hi Valery

On 09/03/2016 11:46, "Valery Smyslov"  wrote:

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

Thanks - sorry, I used the wrong terminology.

Just to confirm  - for the malicious case I setup my webserver
www.evilgraham.com, I send you HASH + URL

http://www.evilgraham.com/djfjkdfkdfkdfjfdj

(hash being 'djfjkdfkdfkdfjfdj')

there’s a file on my server named ‘djfjkdfkdfkdfjfdj’ (Yoav’s 4k movie..)

You now download this movie..

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

Sorry - I wasn’t clear. I was referring to security policy for the CA. So
say your CA issues certs with a RSA 2048bit keypair, you would know the
approx size of the certificates generated. You would know not to download
a cert bigger than X bytes. As I understand some certificate can become
very large (if containing images etc..), there’s no hard set limit on a
certifciate size, but
the ‘security policy' for the CA (what attributes are included would be
known), so an informed decision could be made to the size of the
certificates.

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

I don’t mean IPsec protected interface. Think LAN and WAN. So IKE/IPsec
comes into the WAN interface and then your protected networks are on your
LAN.

Maybe better terminology would have been Management, basically an
interface that isn’t internet (or WAN) facing and not accessible by the
IKE clients (so can’t be turned over). I’ll reword this, thanks for the
pointer.


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

But there’s also the case for someone getting the VPN gateway to connect
to a malicious HTTP server, even for the 16k limit they can drip feed the
file (very slow transfer). Do this a number of times and you could exhaust
all TCP sockets on the VPN gateway (maybe then preventing CRLs being
retried etc).

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

Well - for those careless responders it’s 2 packets to the get the VPN
gateway to download the movie (200k+ packets etc…)

Seems like a nice amplification to me.


>Anyway, isn't the text better be placed in the Security Considerations
>section?

Sure - I can put it in there. I’ll tidy up the words to clear up the
confusion. Thanks for the comments Valery.

cheers

>
>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"  wrote:
>>
>>>Sending a request and directing a server to send an entire movie in 4K
>>>quality using RTP in an interesting amplification attack.
>
>



smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

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

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

[Graham Bartlett (grbartle)]

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"  wrote:

>Sending a request and directing a server to send an entire movie in 4K
>quality using RTP in an interesting amplification attack. 

 



IPSecME Working Group Y. Nir
Internet-Draft   Check Point
Intended status: Standards Track  V. Smyslov
Expires: September 9, 2016ELVIS-PLUS
  G.Bartlett
   Cisco Systems
   March 8, 2016


  Protecting Internet Key Exchange Protocol version 2 (IKEv2)
   Implementations from Distributed Denial of Service Attacks
 draft-ietf-ipsecme-ddos-protection-05

Abstract

   This document recommends implementation and configuration best
   practices for Internet Key Exchange Protocol version 2 (IKEv2)
   Responders, to allow them to resist Denial of Service and Distributed
   Denial of Service attacks.  Additionally, the document introduces a
   new mechanism called "Client Puzzles" that help accomplish this task.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
 


Nir & Smyslov & BartlettExpires September 9, 2016   [Page 1]

Internet-Draft DDoS Protection for IKEv2  March 2016


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of














































 


Nir & Smyslov & BartlettExpires September 9, 2016   [Page 2]

Internet-Draft DDoS Protection for IKEv2  March 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 1.1.  The Stateless Cookie  . . . . . . . . . . . . . . . . . .   3
 1.2.  Conventions Used in This Document . . . . . . . . . . . .   4
   2.  The Vulnerability . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Retention Periods for Half-Open SAs . . . . . . . . . . . . .   8
   5.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Plan for Defending a Responder  . . . . . . . . . . . . . . .  10
 6.1.  Session Resumption  . . . . . . . . . . . . . . . . . . .  13
 6.2.  HASH and URL  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Using Puzzles in the Protocol . . . . . . . . . . . . . . . .  14
 7.1.  Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . .  14
   7.1.1.  Presenting Puzzle . . . . . . . . . . . . . . . . . .  15
   7.1.2.  Solving Puzzle and Returning the Solution . . . . . .  17
   7.1.3.  Computing Puzzle  . . . . . . . . . . . . . . . . . .  18
   7.1.4.  Analyzing Repeated Request  . . . . . . . . . . . . .  18
   7.1.5.  Making Decision whether to Serve the Request  . . . .  20
 7.2.  Puzzles in IKE_AUTH Exchange  . . . . . . . . . . . . . .  21
   7.2.1.  Presenting Puzzle . . . . . . . . . . . . . . . . . .  21
   7.2.2.  Solving Puzzle and Returning the Solution . . . . . .  22
   7.2.3.  Computing Puzzle  . . . . . . . . . . . . . . . . . .  23
   7.2.4.  Receiving Puzzle Solution . . . . . . . . . . . . . .  23
   8.  DoS Protection after IKE SA is created  . . . . . . . . . . .  24
   9.  Payload Formats . . . . . . . . . . . . . . . . . . . . . . .  25
 9.1.  PUZZLE Notification . . . . . . . . . 

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

[Tero Kivinen]

Yoav Nir writes:
> > I¹ve seen an amplification attack, where an implementation (as a
> > responder) would reply to a SA_INIT. If the responder did not receive a
> > reply to its SA_INIT it would re-transmit either 3 or 5 times (can¹t
> > remember exactly). (this seemed to not conform to 2.1 retransmission
> > timers..
> 
> It doesn’t conform.  I think this was more common in IKEv1, but I’m
> not sure why. Maybe because of the need to store a larger state for
> Main Mode.

It was because IKEv1 did not specify request response pairs. Every
message was fire and forget message, and the sender of the mssage was
supposed to take care whether it reached the other end or not. See
section 5.1 of RFC2408:

--
   When transmitting an ISAKMP message, the transmitting entity
   (initiator or responder) MUST do the following:

   1.  Set a timer and initialize a retry counter.

   NOTE: Implementations MUST NOT use a fixed timer.  Instead,
   transmission timer values should be adjusted dynamically based on
   measured round trip times.  In addition, successive
   retransmissions of the same packet should be separated by
   increasingly longer time intervals (e.g., exponential backoff).

   2.  If the timer expires, the ISAKMP message is resent and the retry
   counter is decremented.

   3.  If the retry counter reaches zero (0), the event, RETRY LIMIT
   REACHED, MAY be logged in the appropriate system audit file.

   4.  The ISAKMP protocol machine clears all states and returns to
   IDLE.
--

> In IKEv2 a Responder should only reply once, but store the reply for
> retransmission in case the request is received again.

Yep. See section 2.1 of RFC7296.

> IMHO even in that case this is not an interesting attack. We should
> be worried about amplification attacks where little traffic causes a
> lot of traffic, not a case where I send a 200-byte packet which
> results in a 250-byte packet, and not even a 5 250-byte packets.
> Sending a request and directing a server to send an entire movie in
> 4K quality using RTP in an interesting amplification attack. Using a
> 10-Mbps uplink to generate 12-Mbps of traffic is not. 

The IKEv1 reflection attacks can be bad, as sending single packet, you
can generate 10 packets to be sent over several tens of seconds.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Paul Wouters writes:
> > I agree that puzzles is a controversal thing. However currently we have no
> > better idea how at least to try to defend against powerful botnets. If you 
> > can come up with such an idea, you are very welcome.
> 
> If there is no consensus about puzzles, perhaps we should leave that
> part out of the document?

I think it is good thing to have puzzles in there, even if we do not
enable them now. 

> > And note, that the way puzzles are used in the draft makes every
> > attempt to not discriminate those initiators that don't support puzzles
> > or cannot afford enough power to solve them. In other words -
> > puzzles mechanism in the draft is not an absolute barrier for
> > unsupported clients, it is just a first-class ticket for those who support 
> > and afford.
> 
> which is the botnet more than mobile phones. Which is why I don't see I
> would implement this. It seems session resumption would be more
> effective at distinguishing returning clients from a botnet.

I think it is good idea to have the puzzles already defined, so if
this really comes a problem and puzzles are needed, we already have
solution for that in the specification, we simply need to roll on the
new implementations :-)

I would hope server side gatways would implement those, but most
likely they would only be enabled when someone is really under big
attack.

Also modern mobile phones do have more power than home area switches,
adsl routers, coffee pots and other internet of target devices. Those
very low end devices have so little cpu power that people do not even
care if they are protected or not, and generating huge botnets of them
might be way to make DDoS attacks.

Also even the desktop and laptops do not have that much more raw cpu
power than modern mobile phones. Yes, doing puzzles do consume also
energy on phones, but you simply need to do it once, and then you are
through. Botnets need to use cpu power all the time to beat you.

I.e. phone should be willing to use few seconds of full cpu power to
create the VPN tunnel and then keep it up and running for the whole
day. 

> >>  Recently, I also thought about amplification attacks, which is not
> >>  covered by the document. For instance, legitimate clients could pad
> >>  their IKE_INIT Request as a way to tell the responder they are not just
> >>  using the responder to amplify a DDOS attack. I am thinking of making
> >>  that the default for some Opportunistic IPsec so it cannot be abused for
> >>  amplification. I'd like to see that added to the draft if possible. Or
> >>  if this document would not proceed, I would be tempted to write a draft
> >>  for this idea.
> >
> > Could you, please, elaborate what scenario do you have in mind?
> 
> If you have an IPsec server willing to talk IKE/IPsec to anonymous
> clients. So one-side AUTH_NULL, the other a real authentication. Since
> the server talks to everyone who sends it an IKE_INIT, it is important
> that this IKE_INIT reply is much smaller than the IKE_INIT request,
> so this does not become a new amplification target. Currently, such
> a server could only always require dcookies to accomplish this, but
> that takes an additional round trip. Some kind of padding in the
> IKE_INIT request could easilly prevent this.

IKI_SA_INIT response and IKE_SA_INIT request are almost the same size,
I do not think there is need for padding. 

The SAr1 will always be subset of SAi1, i.e., it is either same size
or smaller. The KEr is same size as KEr. Nr can be selected so that it
is same size as Ni, so there is no difference. Only thing that is in
the response which is not in the request is the CERTREQ if you are
using certificate based authentication, and that is few tens of bytes
(unless you have large number of CAs).

On the other hand request also usually have different notifications
indicating features etc, and in most cases those notifications are
only included in response only if they were also in the request.

You do might want to limit of sending lots of different vendor IDs in
the server, as those might make the packet bigger...

IKEv1 is much different in this case, as if client sends one packet to
server, the server will then reply back and will most likely
retransmit its response back until it gets next packet from client, or
until request times out, thus in IKEv1 it is easy to get amplification
factor of ten (if servers retry limit is for example 10).
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Waltermire, David A. (Fed)]

With my hat off, I like the idea of reorganizing the puzzle oriented content in 
the draft to after the current section 4-6 content. IMHO, I think this could 
improve the flow and organization of the document.

Dave

> -Original Message-
> From: tpa...@apple.com [mailto:tpa...@apple.com]
> Sent: Saturday, March 05, 2016 8:38 PM
> To: Valery Smyslov <sva...@gmail.com>
> Cc: Yoav Nir <ynir.i...@gmail.com>; ipsec@ietf.org; Paul Wouters
> <p...@nohats.ca>; Waltermire, David A. (Fed) <david.walterm...@nist.gov>
> Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
> 
> Hi Valery,
> 
> Responses inline.
> 
> Thanks!
> Tommy
> 
> > On Mar 5, 2016, at 2:00 AM, Valery Smyslov <sva...@gmail.com> wrote:
> >
> > Hi Tommy,
> >
> > thank you for your comments.
> >
> >>>> I tend to agree with Paul that I find it unlikely, from an
> >>>> implementor’s standpoint, that many Initiators will choose to
> >>>> implement the puzzle logic, especially ones that are running on mobile
> devices. It is unlikely that the phones will be able to solve the puzzles 
> quickly
> enough to beat out botnets, and it would be hard to justify the battery
> consumption necessary.
> >>>> That being said, the document does a very good job of explaining
> >>>> the problem space, and the other parts of its solution
> >>>> (rate-limiting and suggesting session resumption) make good sense.
> Perhaps there can be more focus on how a responder can best protect itself
> if indeed the majority of its clients do not support puzzles?
> >
> > Sections 4 - 6 describe measures other than puzzles that the responder can
> use to defend itself against DDoS attack.
> > Do you think it is not enough? Puzzles are a new thing, that's why
> > more text is needed to explain how they are fit into the protocol. However
> the draft is not solely about puzzles, and I think it covers other defending
> techniques in sufficient details.
> 
> Perhaps it would be useful to rearrange the sections to highlight this more
> clearly. The first section about a solution is Puzzles (section 3), followed 
> by
> sections 4-6 which cover other aspects of DDoS avoidance strategies, which is
> then followed by an in-depth explanation of the Puzzles in the protocol
> (sections 7-9). Since the other aspects and sandwiched in between sections
> purely focused on puzzles, the draft really feels like it is about puzzles. 
> What
> if the other approaches were moved before the first puzzles section, so the
> entire section on puzzles can be contiguous?
> 
> >
> >>>> One question on section 7.1.2:
> >>>>
> >>>> If the received message contains a PUZZLE notification and doesn't
> >>>> contain a COOKIE notification, then this message is malformed
> >>>> because it requests to solve the puzzle, but doesn't provide enough
> >>>> information to do it.  In this case the Initiator SHOULD resend
> >>>> IKE_SA_INIT request.  If this situation repeats several times, then
> >>>> it means that something is wrong and the IKE SA cannot be
> >>>> established.
> >>>>
> >>>> I am concerned that the suggestion for the initiator reacting to
> malformed IKE_SA_INIT packets is to send more traffic to the responder.
> >>>> The responder should not legitimately send a PUZZLE notification
> without a COOKIE notification, since this would be invalid.
> >>>> If the initiator sees this, it can either assume that (a) the
> >>>> responder’s implementation is out of spec, or (b) some malicious
> >>>> third party is deliberately modifying the unencrypted packet. In
> >>>> the first case, trying to send the IKE_SA_INIT again would be in vain; in
> the second case, we have provided a way for a third party to cause initiators
> to send more traffic to the responder, thus providing an attack vector. What
> are your thoughts on this?
> >>>>
> >>> A proper responder would not send a malformed packet. An attacker
> >>> could send a malformed response immediately after the initiator sends
> the request. By the time the initiator gets the real responder’s response, it
> has lost state.
> >>>
> >>> That is why it is always a good idea (not just in this context) for the
> initiator to ignore malformed responses until the timeout is reached.
> >>>
> >> That makes sense. The wording, however, could imply that the Initiator
> should resend the request as if in response to the malfor

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

[Yoav Nir]

> On 4 Mar 2016, at 5:29 PM, Paul Wouters  wrote:
> 
>> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) 
>>  wrote:
>>  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.
> 
> I think the document is well written with respect to DDOS. I like
> everything except the puzzles. It seems a lot of complexity for
> no gain, especially with the problem being that botnets are better
> at puzzle solving then mobile phones who want to not drain their
> batteries.

I wish we had better numbers on the actual power of mobile phones. It’s all a 
question of how many times they can perform PRF-HMAC-SHA256 per second. Tommy?

Regardless, FWIW I (with implementer hat on) would implement DDoS puzzles. As 
the draft suggests, they would be used selectively and only as a last resort. I 
also think that if we had IPsec everywhere as Paul would like, DDoS attacks on 
IKE responders (which is basically all of the Internet) would become much more 
attractive. As it is, with IPsec-based remote access the VPN gateway is an 
attractive target, so we should have more aggressive methods in our arsenal.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> On 6 Mar 2016, at 5:28 PM, Graham Bartlett (grbartle)  
> wrote:
> 
> Hi
> 
> The only case I could imagine that this could occur is if the Initiators
> Nonce and KE were purposely made very small and the Initiator did not
> perform any validation on this, sending it¹s own reply where the KE and
> Nonce were considerably larger.
> 
> I¹ve seen an amplification attack, where an implementation (as a
> responder) would reply to a SA_INIT. If the responder did not receive a
> reply to its SA_INIT it would re-transmit either 3 or 5 times (can¹t
> remember exactly). (this seemed to not conform to 2.1 retransmission
> timers..

It doesn’t conform.  I think this was more common in IKEv1, but I’m not sure 
why. Maybe because of the need to store a larger state for Main Mode.

In IKEv2 a Responder should only reply once, but store the reply for 
retransmission in case the request is received again.

IMHO even in that case this is not an interesting attack. We should be worried 
about amplification attacks where little traffic causes a lot of traffic, not a 
case where I send a 200-byte packet which results in a 250-byte packet, and not 
even a 5 250-byte packets. Sending a request and directing a server to send an 
entire movie in 4K quality using RTP in an interesting amplification attack. 
Using a 10-Mbps uplink to generate 12-Mbps of traffic is not.

Yoav



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Graham Bartlett (grbartle)]

Hi

The only case I could imagine that this could occur is if the Initiators
Nonce and KE were purposely made very small and the Initiator did not
perform any validation on this, sending it¹s own reply where the KE and
Nonce were considerably larger.

I¹ve seen an amplification attack, where an implementation (as a
responder) would reply to a SA_INIT. If the responder did not receive a
reply to its SA_INIT it would re-transmit either 3 or 5 times (can¹t
remember exactly). (this seemed to not conform to 2.1 retransmission
timers..

cheers

On 05/03/2016 13:11, "IPsec on behalf of Valery Smyslov"
 wrote:

>IKE_SA_INIT reply in most cases is smaller than request.
>The responder returns only a subset of initiator's SA transforms,
>a subset of initiator's  notifications (returning only supported ones),
>and usually only a subset of VIDs.
>In which real life scenario it is larger than request?


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

> On Mar 5, 2016, at 5:11 AM, Valery Smyslov  wrote:
> 
>> If there is no consensus about puzzles, perhaps we should leave that
>> part out of the document?
> 
> I had an impression that threre was a consensus when
> the document was adopted by WG. In any case, I think that it is better to 
> have an interoperable specification than to leave puzzles at all (and thus 
> make them a subject
> for a proprietary solutions).

I agree that interoperability is key, and having a definition is useful if 
anyone will be implementing it. 

> 
>>> And note, that the way puzzles are used in the draft makes every
>>> attempt to not discriminate those initiators that don't support puzzles
>>> or cannot afford enough power to solve them. In other words -
>>> puzzles mechanism in the draft is not an absolute barrier for
>>> unsupported clients, it is just a first-class ticket for those who support 
>>> and afford.
>> 
>> which is the botnet more than mobile phones. Which is why I don't see I
>> would implement this. It seems session resumption would be more
>> effective at distinguishing returning clients from a botnet.
> 
> Sure. But before every client becomes a "returning" one it must pass usual 
> IKE_SA_INIT. And it cannot be a returning client the rest of its
> life - it must be fully reauthenticated from time to time.
> Thus the resumption cannot make the task of DDoS protection in IKE_SA_INIT 
> non-existent.

Going along with Paul’s point, it does seem that the approach of session 
resumption would favor the legitimate mobile-device client, where the puzzle 
approach may unintentionally favor the botnets themselves. But it is also a 
good point that session resumption alone cannot solve the DDoS problem.

Would it be possible, I wonder, to try to combine these approaches to create a 
solution that has the responder-protecting properties of puzzles, while still 
favoring legitimate clients? This would require using some property of 
legitimate clients (who will be able to successfully authenticate later in the 
negotiation) as part of the puzzle-challenge, or a way to skew the results in 
their favor. I’m not sure if this is possible from the algorithmic perspective, 
but it would be interesting to use some pre-known value (a shared secret, an 
initiator or responder ID, etc) as a key to the puzzle that, if known, would 
allow a quicker solution. It should be impossible to tell what this original 
key or salt is from an eavesdropper’s perspective, but it could make the 
calculation quicker for a client with a weak processor that was correctly 
provisioned to communicate with the server.

Thanks,
Tommy

> 
>>> Could you, please, elaborate what scenario do you have in mind?
>> 
>> If you have an IPsec server willing to talk IKE/IPsec to anonymous
>> clients. So one-side AUTH_NULL, the other a real authentication. Since
>> the server talks to everyone who sends it an IKE_INIT, 
> 
> How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder
> doesn't yet know that the initiator will use NULL auth or real auth, so any 
> server usually replies to everyone who sends IKE_SA_INIT request.
> 
>> it is important
>> that this IKE_INIT reply is much smaller than the IKE_INIT request,
>> so this does not become a new amplification target. 
> 
> IKE_SA_INIT reply in most cases is smaller than request.
> The responder returns only a subset of initiator's SA transforms, a subset of 
> initiator's  notifications (returning only supported ones),
> and usually only a subset of VIDs.
> In which real life scenario it is larger than request?
> 
>> Currently, such
>> a server could only always require dcookies to accomplish this, but
>> that takes an additional round trip. Some kind of padding in the
>> IKE_INIT request could easilly prevent this.
> 
> Sorry, I failed to understand how additional padding would work.
> Are you going to reject initiators that don't include this additional padding
> (i.e. - all usual IKEv2 clients)? Am I missing something?
> 
> Regards,
> Valery.
> 
>> Paul
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

Hi Valery,

Responses inline.

Thanks!
Tommy

> On Mar 5, 2016, at 2:00 AM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> thank you for your comments.
> 
 I tend to agree with Paul that I find it unlikely, from an implementor’s 
 standpoint, that many Initiators will choose
 to implement the puzzle logic, especially ones that are running on mobile 
 devices. It is unlikely that the phones will be able
 to solve the puzzles quickly enough to beat out botnets, and it would be 
 hard to justify the battery consumption necessary.
 That being said, the document does a very good job of explaining the 
 problem space, and the other parts of its solution
 (rate-limiting and suggesting session resumption) make good sense. Perhaps 
 there can be more focus on how a responder
 can best protect itself if indeed the majority of its clients do not 
 support puzzles?
> 
> Sections 4 - 6 describe measures other than puzzles that the responder can 
> use to defend itself against DDoS attack.
> Do you think it is not enough? Puzzles are a new thing, that's why more text 
> is needed to explain how they are fit
> into the protocol. However the draft is not solely about puzzles, and I think 
> it covers other defending techniques in sufficient details.

Perhaps it would be useful to rearrange the sections to highlight this more 
clearly. The first section about a solution is Puzzles (section 3), followed by 
sections 4-6 which cover other aspects of DDoS avoidance strategies, which is 
then followed by an in-depth explanation of the Puzzles in the protocol 
(sections 7-9). Since the other aspects and sandwiched in between sections 
purely focused on puzzles, the draft really feels like it is about puzzles. 
What if the other approaches were moved before the first puzzles section, so 
the entire section on puzzles can be contiguous?

> 
 One question on section 7.1.2:
 
 If the received message contains a PUZZLE notification and doesn't
 contain a COOKIE notification, then this message is malformed because
 it requests to solve the puzzle, but doesn't provide enough
 information to do it.  In this case the Initiator SHOULD resend
 IKE_SA_INIT request.  If this situation repeats several times, then
 it means that something is wrong and the IKE SA cannot be
 established.
 
 I am concerned that the suggestion for the initiator reacting to malformed 
 IKE_SA_INIT packets is to send more traffic to the responder.
 The responder should not legitimately send a PUZZLE notification without a 
 COOKIE notification, since this would be invalid.
 If the initiator sees this, it can either assume that (a) the responder’s 
 implementation is out of spec, or (b) some malicious third party
 is deliberately modifying the unencrypted packet. In the first case, 
 trying to send the IKE_SA_INIT again would be in vain;
 in the second case, we have provided a way for a third party to cause 
 initiators to send more traffic to the responder,
 thus providing an attack vector. What are your thoughts on this?
 
>>> A proper responder would not send a malformed packet. An attacker could 
>>> send a malformed response immediately
>>> after the initiator sends the request. By the time the initiator gets the 
>>> real responder’s response, it has lost state.
>>> 
>>> That is why it is always a good idea (not just in this context) for the 
>>> initiator to ignore malformed responses until the timeout is reached.
>>> 
>> That makes sense. The wording, however, could imply that the Initiator 
>> should resend the request as if in response to the malformed packet.
>> Based on your comment, the Initiator should wait for the usual amount of 
>> time before retrying, rather than immediately retrying the packet.
>> It may be useful to clarify this in the text.
> 
> You are right that the Initiator should wait for the retransission timer to 
> expire before resending message.
> I agree that the wording is ambiguous about that. How about the following?
> 
>  If the received message contains a PUZZLE notification and doesn't
>  contain a COOKIE notification, then this message is malformed because
>  it requests to solve the puzzle, but doesn't provide enough
>  information to do it.  In this case the Initiator MUST ignore
>  the received message and continue to wait until either the valid one
>  is received or the retransmission timer fires. If it fails to receive the 
> valid
>  message after several retransmissions of IKE_SA_INIT request, then
>  it means that something is wrong and the IKE SA cannot be established.

I think that is more clear, thanks!
> 
> Regards,
> Valery.
> 
>> Thanks,
>> Tommy
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org

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

[Valery Smyslov]

If there is no consensus about puzzles, perhaps we should leave that
part out of the document?


I had an impression that threre was a consensus when
the document was adopted by WG. In any case, I think that 
it is better to have an interoperable specification 
than to leave puzzles at all (and thus make them a subject

for a proprietary solutions).


And note, that the way puzzles are used in the draft makes every
attempt to not discriminate those initiators that don't support puzzles
or cannot afford enough power to solve them. In other words -
puzzles mechanism in the draft is not an absolute barrier for
unsupported clients, it is just a first-class ticket for those who support 
and afford.


which is the botnet more than mobile phones. Which is why I don't see I
would implement this. It seems session resumption would be more
effective at distinguishing returning clients from a botnet.


Sure. But before every client becomes a "returning" one it must pass 
usual IKE_SA_INIT. And it cannot be a returning client the rest of its

life - it must be fully reauthenticated from time to time.
Thus the resumption cannot make the task of DDoS protection in 
IKE_SA_INIT non-existent.



Could you, please, elaborate what scenario do you have in mind?


If you have an IPsec server willing to talk IKE/IPsec to anonymous
clients. So one-side AUTH_NULL, the other a real authentication. Since
the server talks to everyone who sends it an IKE_INIT, 


How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder
doesn't yet know that the initiator will use NULL auth or real auth, so 
any server usually replies to everyone who sends IKE_SA_INIT request.



it is important
that this IKE_INIT reply is much smaller than the IKE_INIT request,
so this does not become a new amplification target. 


IKE_SA_INIT reply in most cases is smaller than request.
The responder returns only a subset of initiator's SA transforms, 
a subset of initiator's  notifications (returning only supported ones),

and usually only a subset of VIDs.
In which real life scenario it is larger than request?


Currently, such
a server could only always require dcookies to accomplish this, but
that takes an additional round trip. Some kind of padding in the
IKE_INIT request could easilly prevent this.


Sorry, I failed to understand how additional padding would work.
Are you going to reject initiators that don't include this additional padding
(i.e. - all usual IKEv2 clients)? Am I missing something?

Regards,
Valery.


Paul


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Paul,

thank you for your comments.


I think the document is well written with respect to DDOS. I like
everything except the puzzles. It seems a lot of complexity for
no gain, especially with the problem being that botnets are better
at puzzle solving then mobile phones who want to not drain their
batteries. I would prefer this document to proceed without the
puzzles, but I won't object to it if it remains in the document.
As an implementor, it would be extremely unlikely that I would
implement puzzles.


I agree that puzzles is a controversal thing. However currently we have no
better idea how at least to try to defend against powerful botnets. If you can
come up with such an idea, you are very welcome.

(W.Churchill said that democracy is the worst form of government,
except all those others that have been tried. [1]
I think that's a good analogy for puzzles.)

And note, that the way puzzles are used in the draft makes every
attempt to not discriminate those initiators that don't support puzzles
or cannot afford enough power to solve them. In other words -
puzzles mechanism in the draft is not an absolute barrier for
unsupported clients, it is just a first-class ticket for those who support and 
afford.


Recently, I also thought about amplification attacks, which is not
covered by the document. For instance, legitimate clients could pad
their IKE_INIT Request as a way to tell the responder they are not just
using the responder to amplify a DDOS attack. I am thinking of making
that the default for some Opportunistic IPsec so it cannot be abused for
amplification. I'd like to see that added to the draft if possible. Or
if this document would not proceed, I would be tempted to write a draft
for this idea.


Could you, please, elaborate what scenario do you have in mind?


Paul


Regards,
Valery.

[1] 
http://www.academia.edu/1877336/_It_has_been_said_that_democracy_is_the_worst_form_of_government_except_all_those_others_that_have_been_tried_Winston_Churchill


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Tommy,

thank you for your comments.

I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will 
choose
to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones 
will be able
to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption 
necessary.
That being said, the document does a very good job of explaining the problem space, and the other parts of its 
solution
(rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a 
responder

can best protect itself if indeed the majority of its clients do not support 
puzzles?


Sections 4 - 6 describe measures other than puzzles that the responder can use 
to defend itself against DDoS attack.
Do you think it is not enough? Puzzles are a new thing, that's why more text is 
needed to explain how they are fit
into the protocol. However the draft is not solely about puzzles, and I think it covers other defending techniques in 
sufficient details.



One question on section 7.1.2:

If the received message contains a PUZZLE notification and doesn't
contain a COOKIE notification, then this message is malformed because
it requests to solve the puzzle, but doesn't provide enough
information to do it.  In this case the Initiator SHOULD resend
IKE_SA_INIT request.  If this situation repeats several times, then
it means that something is wrong and the IKE SA cannot be
established.

I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more 
traffic to the responder.
The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be 
invalid.
If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some 
malicious third party
is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be 
in vain;
in the second case, we have provided a way for a third party to cause initiators to send more traffic to the 
responder,

thus providing an attack vector. What are your thoughts on this?


A proper responder would not send a malformed packet. An attacker could send a 
malformed response immediately
after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost 
state.


That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until 
the timeout is reached.


That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to 
the malformed packet.
Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately 
retrying the packet.

It may be useful to clarify this in the text.


You are right that the Initiator should wait for the retransission timer to 
expire before resending message.
I agree that the wording is ambiguous about that. How about the following?

  If the received message contains a PUZZLE notification and doesn't
  contain a COOKIE notification, then this message is malformed because
  it requests to solve the puzzle, but doesn't provide enough
  information to do it.  In this case the Initiator MUST ignore
  the received message and continue to wait until either the valid one
  is received or the retransmission timer fires. If it fails to receive the 
valid
  message after several retransmissions of IKE_SA_INIT request, then
  it means that something is wrong and the IKE SA cannot be established.

Regards,
Valery.


Thanks,
Tommy


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

> On Mar 4, 2016, at 9:32 AM, Yoav Nir  wrote:
> 
>> 
>> On 4 Mar 2016, at 7:02 PM, Tommy Pauly  wrote:
>> 
>> Hello Dave,
>> 
>> I tend to agree with Paul that I find it unlikely, from an implementor’s 
>> standpoint, that many Initiators will choose to implement the puzzle logic, 
>> especially ones that are running on mobile devices. It is unlikely that the 
>> phones will be able to solve the puzzles quickly enough to beat out botnets, 
>> and it would be hard to justify the battery consumption necessary. That 
>> being said, the document does a very good job of explaining the problem 
>> space, and the other parts of its solution (rate-limiting and suggesting 
>> session resumption) make good sense. Perhaps there can be more focus on how 
>> a responder can best protect itself if indeed the majority of its clients do 
>> not support puzzles?
>> 
>> One question on section 7.1.2:
>> 
>> If the received message contains a PUZZLE notification and doesn't
>>  contain a COOKIE notification, then this message is malformed because
>>  it requests to solve the puzzle, but doesn't provide enough
>>  information to do it.  In this case the Initiator SHOULD resend
>>  IKE_SA_INIT request.  If this situation repeats several times, then
>>  it means that something is wrong and the IKE SA cannot be
>>  established.
>> 
>> I am concerned that the suggestion for the initiator reacting to malformed 
>> IKE_SA_INIT packets is to send more traffic to the responder. The responder 
>> should not legitimately send a PUZZLE notification without a COOKIE 
>> notification, since this would be invalid. If the initiator sees this, it 
>> can either assume that (a) the responder’s implementation is out of spec, or 
>> (b) some malicious third party is deliberately modifying the unencrypted 
>> packet. In the first case, trying to send the IKE_SA_INIT again would be in 
>> vain; in the second case, we have provided a way for a third party to cause 
>> initiators to send more traffic to the responder, thus providing an attack 
>> vector. What are your thoughts on this?
> 
> A proper responder would not send a malformed packet. An attacker could send 
> a malformed response immediately after the initiator sends the request. By 
> the time the initiator gets the real responder’s response, it has lost state. 
> 
> That is why it is always a good idea (not just in this context) for the 
> initiator to ignore malformed responses until the timeout is reached.

That makes sense. The wording, however, could imply that the Initiator should 
resend the request as if in response to the malformed packet. Based on your 
comment, the Initiator should wait for the usual amount of time before 
retrying, rather than immediately retrying the packet. It may be useful to 
clarify this in the text.

Thanks,
Tommy

> 
> Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> On 4 Mar 2016, at 7:02 PM, Tommy Pauly  wrote:
> 
> Hello Dave,
> 
> I tend to agree with Paul that I find it unlikely, from an implementor’s 
> standpoint, that many Initiators will choose to implement the puzzle logic, 
> especially ones that are running on mobile devices. It is unlikely that the 
> phones will be able to solve the puzzles quickly enough to beat out botnets, 
> and it would be hard to justify the battery consumption necessary. That being 
> said, the document does a very good job of explaining the problem space, and 
> the other parts of its solution (rate-limiting and suggesting session 
> resumption) make good sense. Perhaps there can be more focus on how a 
> responder can best protect itself if indeed the majority of its clients do 
> not support puzzles?
> 
> One question on section 7.1.2:
> 
> If the received message contains a PUZZLE notification and doesn't
>   contain a COOKIE notification, then this message is malformed because
>   it requests to solve the puzzle, but doesn't provide enough
>   information to do it.  In this case the Initiator SHOULD resend
>   IKE_SA_INIT request.  If this situation repeats several times, then
>   it means that something is wrong and the IKE SA cannot be
>   established.
> 
> I am concerned that the suggestion for the initiator reacting to malformed 
> IKE_SA_INIT packets is to send more traffic to the responder. The responder 
> should not legitimately send a PUZZLE notification without a COOKIE 
> notification, since this would be invalid. If the initiator sees this, it can 
> either assume that (a) the responder’s implementation is out of spec, or (b) 
> some malicious third party is deliberately modifying the unencrypted packet. 
> In the first case, trying to send the IKE_SA_INIT again would be in vain; in 
> the second case, we have provided a way for a third party to cause initiators 
> to send more traffic to the responder, thus providing an attack vector. What 
> are your thoughts on this?

A proper responder would not send a malformed packet. An attacker could send a 
malformed response immediately after the initiator sends the request. By the 
time the initiator gets the real responder’s response, it has lost state. 

That is why it is always a good idea (not just in this context) for the 
initiator to ignore malformed responses until the timeout is reached.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

Hello Dave,

I tend to agree with Paul that I find it unlikely, from an implementor’s 
standpoint, that many Initiators will choose to implement the puzzle logic, 
especially ones that are running on mobile devices. It is unlikely that the 
phones will be able to solve the puzzles quickly enough to beat out botnets, 
and it would be hard to justify the battery consumption necessary. That being 
said, the document does a very good job of explaining the problem space, and 
the other parts of its solution (rate-limiting and suggesting session 
resumption) make good sense. Perhaps there can be more focus on how a responder 
can best protect itself if indeed the majority of its clients do not support 
puzzles?

One question on section 7.1.2:

If the received message contains a PUZZLE notification and doesn't
   contain a COOKIE notification, then this message is malformed because
   it requests to solve the puzzle, but doesn't provide enough
   information to do it.  In this case the Initiator SHOULD resend
   IKE_SA_INIT request.  If this situation repeats several times, then
   it means that something is wrong and the IKE SA cannot be
   established.

I am concerned that the suggestion for the initiator reacting to malformed 
IKE_SA_INIT packets is to send more traffic to the responder. The responder 
should not legitimately send a PUZZLE notification without a COOKIE 
notification, since this would be invalid. If the initiator sees this, it can 
either assume that (a) the responder’s implementation is out of spec, or (b) 
some malicious third party is deliberately modifying the unencrypted packet. In 
the first case, trying to send the IKE_SA_INIT again would be in vain; in the 
second case, we have provided a way for a third party to cause initiators to 
send more traffic to the responder, thus providing an attack vector. What are 
your thoughts on this?

Thanks,
Tommy


> On Mar 4, 2016, at 7:29 AM, Paul Wouters  wrote:
> 
>> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) 
>>  wrote:
>>  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.
> 
> I think the document is well written with respect to DDOS. I like
> everything except the puzzles. It seems a lot of complexity for
> no gain, especially with the problem being that botnets are better
> at puzzle solving then mobile phones who want to not drain their
> batteries. I would prefer this document to proceed without the
> puzzles, but I won't object to it if it remains in the document.
> As an implementor, it would be extremely unlikely that I would
> implement puzzles.
> 
> Recently, I also thought about amplification attacks, which is not
> covered by the document. For instance, legitimate clients could pad
> their IKE_INIT Request as a way to tell the responder they are not just
> using the responder to amplify a DDOS attack. I am thinking of making
> that the default for some Opportunistic IPsec so it cannot be abused for
> amplification. I'd like to see that added to the draft if possible. Or
> if this document would not proceed, I would be tempted to write a draft
> for this idea.
> 
> Paul
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) 
 wrote:
  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.


I think the document is well written with respect to DDOS. I like
everything except the puzzles. It seems a lot of complexity for
no gain, especially with the problem being that botnets are better
at puzzle solving then mobile phones who want to not drain their
batteries. I would prefer this document to proceed without the
puzzles, but I won't object to it if it remains in the document.
As an implementor, it would be extremely unlikely that I would
implement puzzles.

Recently, I also thought about amplification attacks, which is not
covered by the document. For instance, legitimate clients could pad
their IKE_INIT Request as a way to tell the responder they are not just
using the responder to amplify a DDOS attack. I am thinking of making
that the default for some Opportunistic IPsec so it cannot be abused for
amplification. I'd like to see that added to the draft if possible. Or
if this document would not proceed, I would be tempted to write a draft
for this idea.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Fri, 4 Mar 2016, Dr. Karan Verma wrote:

[ Did this go way of-topic? This does not relate to DDOS at all? ]


1. The root CA certificate corresponding to the server certificate must be 
installed on the client computers in the
Trusted Root Certification Authorities per-computer certificate store. The 
client computer must be able to validate
the server certificate as being signed by a trusted root CA.


Unless other AUTH mechanisms are used?


2. If I keep my user and server key to a 2048-bit one it appears to be fine.


You are lucky. 2048 bit certificates regularly cause fragmentation.


There's an RFC for this and support on recent Strong swan releases but the 
client has to ask for it during initial
negotiation and the BB10 client does not.  The result is that longer (and 
more-secure) keys won't work -- if you have
either a 4096-bit server certificate or a 4096-bit user cert the VPN will not 
come up.


Yes, strongswan, libreswan and even iOS I think support fragmentation for IKEv2.


 3. First, we have incompatibility between IPsec AH and NAT.   This   is   
because   AH   header   incorporates  
the   IP source   and   destination   addresses   in the keyed message 
integrity check and therefore NAT will
invalidate message integrity check by changing address fields. This makes A 
unusable in the presence of NAT devices.
ESP doesn't have this problem because it doesn't incorporate the IP header 
inits keyed message integrity check, so
changes in IP header will not conflict with ESP's integrity protection.


You should not use AH. Use ESP_NULL instead in Tunnel Mode.


A more serious problem that affects both AH and ESP is incompatibility between  
 transport   layer   checksums   and
NAT. This problem occurs with AH and ESP in transport mode.


Don't use Transport Mode. The few bytes gained are not worth the hassle.


There is also incompatibility between IKEv2 address identifiers   and   NAT.   
Some   phases   of   IKEv2   use   IP
addresses as identifiers. Modification of these addresses through NAT will 
cause mismatch between identifiers and the
addresses in the IP header. The solution to this problem might   be   the   use 
  of   user   IDs   or   FQDNs  
that   are independent of IP addresses.


I dont understand this at all. For any incoming IKE request that is not
an IKE_INIT request, you have the SPI numbers that uniquely identify the
IKE SA to match. In IKE_AUTH you are told the AUTH method to use, which
can be anything. Outside of IKE_INIT and IKE_AUTH you are already
authenticated and have your SPI's to match your connection.



IKE   protocol   requires   use   of   fixed   source   and destination  
ports.   This   also   causes   incompatibility with NAT. One possible scenario 
that might cause problems is when
multiple hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same 
responder. Mechanism is needed to
allow the NAPT to DE multiplex the incoming IKE   packets   from   responder.


The NAT box will assign a different outgoing port for the second client
trying to use port 4500 as outgoing source port. There is no problem.


   This   is   typically accomplished by
translating the IKE UDP source port on outbound   packets   from   initiator.   
Because   of   that responders  
must   be   able   to   accept   IKE   traffic   from   a various  source  
ports   (other  than  500   on  which  is 
IKE running)


You are mixing up source port and destination port here. IKE daemons
only need to listen on port 500 and 4500. And they should accept any
port for the incoming IKE packets.


, and must reply to that port. The somewhat similar problem, but in it's own 
category, are the
incompatibilities between overlapping SPD entries when using NAT.


We have a draft for that we will be updating soon. But you can also work
locally on this. For example on linux you can add MARKing to the packet
and have two identical SPD's that only differ by the mark. That means
you can receive and reply conflicting SPDs fine, except you cannot
initiate traffic to one specific SPD unless you manually mark your
packet.


   There are situations when responder could send
packets down the wrong IPsec SA because of overlapping   SPD   entries.


That would be an implementation bug.

   This   could   happen   when initiating

hosts behind NAT use their source IP addresses in Phase 2 identifiers.


I think you refer to two machines on 192.168.1.1 behind two different
NAT routers? There should not be a problem but again you will need to
use our natt draft lik approach or MARKing of some kind.

 Another problem between ESP  and NAT   lies 

in  thein compatibility   between   IPsec   SPI   selection   and   NAT. Since 
IPsec ESP traffic is encrypted, only
way for NATs to know how to demultiplex incoming packets is to inspect 
information’s in the IP and ESP header. These


NAT's don't need to demultiplex anything. They just need to conntrack
the local IP's and ports they assigned, and return