Subject: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Jan 2015 09:24:43 -0800

Greetings again. The chairs apologize for the log delay on this, but it is time to move on this document. This begins the two-week WG Last Call on https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. The purpose of the WG Last Call is to get as many people as possible to read the document carefully, looking for any technical or editorial issues that should be discussed before the document is sent to the IETF.

I certainly hope we can get thorough reviews from the people who supported its adoption as a WG item, but the WG would also benefit from anyone else doing a review as well. Please send all comments to the list before Friday, January 23. Thanks!

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Jan 2015 15:28:11 -0500 (EST)

> Greetings again. The chairs apologize for the log delay on this, but it is time to move on this document. This begins the two-week WG Last Call on https://tools.ietf.org/html/draft-smyslov-ipsecme-…

Paul meant:

https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth

> I certainly hope we can get thorough reviews from the people who supported its adoption as a WG item, but the WG would also benefit from anyone else doing a review as well. Please send all comments…

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Jan 2015 13:06:28 -0800

> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth

Blarg, I certainly did. I have no idea how that happened in my tool chain.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 11 Jan 2015 17:24:44 +0200

Hi Valery,

Please see my comments below.

- Unclosed sentence in the abstract: "It may be used to preserve 
anonymity of"

- Reference to IKEv2: please use RFC 7296.

- 2.1: it may be trivial, but we want to add that the AUTH payload MUST 
be verified by the recipient.

- I don't think that we have consensus on "The Identification Data in 
Identity payload for the ID_NULL type MUST be absent". The asserted but 
unproven identity may be used for logging, or may be proven with a later 
authentication. Quoting from an email by Tero: "I think the most 
important point of this feature is that the client is UNAUTHENTICATED, 
not that it is ANONYMOUS."

- "If endpoint receives a request to create an unauthenticated IKE SA 
from the IP address, which is configured on the endpoint to be 
authenticated, the request SHOULD be rejected." - I don't see why. What 
if there are several peers behind an IP address, some authenticated and 
some not? Maybe we need to think some more about the policy that each of 
the peers should enforce.

- The issue of Traffic Selectors needs better treatment. Should we add a 
MUST for allocation of internal IP addresses?

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Sun, 11 Jan 2015 11:34:24 -0500 (EST)

On Sun, 11 Jan 2015, Yaron Sheffer wrote:

I sent Valery an updated version which he can hopefully incorporate in
this WGLC. I'll just comment on Yaron's remarks below.

> - Unclosed sentence in the abstract: "It may be used to preserve anonymity 
> of"

I suggested a rewriten abstract to Valery.

> - Reference to IKEv2: please use RFC 7296.

Did that.

> - 2.1: it may be trivial, but we want to add that the AUTH payload MUST be 
> verified by the recipient.

Sure.

> authentication. Quoting from an email by Tero: "I think the most important 
> point of this feature is that the client is UNAUTHENTICATED, not that it is 
> ANONYMOUS."

I think you mean to say the NULL Authentication Method does not require
ID_NULL. But obviously ID_NULL cannot have a payload. Because if you
give it one, what type would it be? :P

> - "If endpoint receives a request to create an unauthenticated IKE SA from 
> the IP address, which is configured on the endpoint to be authenticated, the 
> request SHOULD be rejected." - I don't see why. What if there are several 
> peers behind an IP address, some authenticated and some not? Maybe we need to 
> think some more about the policy that each of the peers should enforce.
>
> - The issue of Traffic Selectors needs better treatment. Should we add a MUST 
> for allocation of internal IP addresses?

These issues are difficult and need to be addressed in the "opoprtunistic
ipsec" document. I'm not sure how much of this discussion belongs in
this document. I would prefer if this document keeps it focus on the
format of the Null Authentication Method and ID_NONE payloads.
(I think what I put in my suggestions to Valery is already too much for
this document)

If you have more peers behind the same NAT, you need a GOOD strategy for
containing those private IPs or else one of those clients is going to
use 8.8.8.8 and steal the servers DNS traffic.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 11 Jan 2015 22:59:28 +0200

Hi Paul, Valery,

Please see below.

Thanks,
	Yaron

> I suggested a rewriten abstract to Valery.

If there's a newer and cleaner version of the draft, can you please 
submit it to make all our lives somewhat easier.

>> - 2.1: it may be trivial, but we want to add that the AUTH payload
>> MUST be verified by the recipient.
>
> Sure.
>
>> Identity payload for the ID_NULL type MUST be absent". The asserted
>> but unproven identity may be used for logging, or may be proven with a
>> later authentication. Quoting from an email by Tero: "I think the most

Agreed. I would prefer the NULL Authentication Method to not require 
ID_NULL.

>> authenticated, the request SHOULD be rejected." - I don't see why.
>> What if there are several peers behind an IP address, some
>> authenticated and some not? Maybe we need to think some more about the
>> policy that each of the peers should enforce.
>>
>> - The issue of Traffic Selectors needs better treatment. Should we add
>> a MUST for allocation of internal IP addresses?
>

I tend to agree. But in that case, the above two points need to be 
removed from the draft. And a more detailed (non-normative!) placeholder 
added to the Security Considerations, so that until we have an 
"opportunistic IPsec" draft, people will know where the minefields are.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Jan 2015 10:06:16 -0500 (EST)

>> https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth

So since the WGLC came onto us a little early, the document authors
still have some different opinions about some of this. So let me raise
those in the WGLC :)

INITIAL_CONTACT

Section 2.3 tries to address the problem of not being able to trust
INITIAL_CONTACT. Normally this payload is only honoured after
authentication, but we don't have a real authentication here, and one
anonymous IKE SA should not be allowed to obsolete another IKE SA.

Valery suggests sending liveness checks to all IKE SA's that used
AUTH_NONE.

I suggested sending liveness checks only to those IKE SA's that used
the same IP address, thus limiting the scope to a more likely pool
of possible orphaned SA's by a remote that crashed/restarted.

Of course, implementations can be smart, and skip liveness checks for
those IKE SA's whose IPsec SA is showing traffic now in in the very
recent past.

We need to consider the harm of leaving orphaned SA's versus the harm
of being tricked into sending too many liveness probes.

And in general, we need to ensure one IKE SA isn't sending a zillion
useless IKE messages - as we've lost the protection of a real
authentication to punish abusers by locking them out. (if you thought
ddos-puzzles were interesting, come tackle this problem :)

Traffic Selectors

We touched a bit on the traffic selector problem. If a peer is able
to pick its own address, it could attempt to steal traffic (say 8.8.8.8)
from the server. We advise people to isolate these peers. We cannot
fully disallow this because we need NAT-traversal support. Valery
preferred server assigned IP addresses (using CP) which will work great
in the "sensor network" but would cause overlapping problems with IKE
peers that talk to multiple peers that hand out their own range of
addresses. And opens up the reverse attack of the server stealing the
client's 8.8.8.8 traffic. Some more discussion and insights on this
would be useful.

Additionally, if we allow some kind of narrowed traffic selector,
malicious IKE peers would only need their one IP and could setup
(protocol * sport * dport) IPsec SAs. Or a variant of this could
be done with when allowing CREATE_CHILD_SA to setup a plethora of
IPsec SAs. Restrictions based on IP address is hard, again because
of the NAT support problem.

What we tried to do with the security consideration section is to keep
advise generic. Then specific opportunistic IPsec related issues could
find themselves in a soon to be draft-ipsec-opportunistic document.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 Jan 2015 18:16:59 -0500 (EST)

On Tue, 13 Jan 2015, Graham Bartlett (grbartle) wrote:

> Hi Valery / Paul

[ CC:ing this back to the list ]

>>> Or maybe you have 1000 sensors and there is only 250 IP addresses in the
>>> DHCP pool, as you say the sensor is meant to wake, then send, then
>>> sleep.
>>> But it wakes, sends and keeps the IKE SA open, which prevents other
>>> sensors connecting.
>>
>> Please, see above. I assumed it should delete IKE SA before going into
>> sleep.
>
> It should delete the SA (in a perfect world), but what if it didn't sleep
> and stayed awake forever.. As peers can't be authenticated then it allows
> an easy self inflicted DOS. :-)

Well, anonymous IPsec is a self inflicted DOS :)

If it remains awake then normal liveness checks combined with IKE/IPsec SA
lifetimes should handle the cleanup.

> What I was alluding to is covered now in section 3.2 (and in Paul's
> email). However I think some final words at the end of 3.2 such as 'For
> this reason systems should be designed to accommodate legitimate and
> non-legitimate non-authenticated peers', would then make this message
> crystal clear.

Can you propose text? I personally find "legitimate and non-legitimate
non-authenticated peers" very unclear. I don't think a server can ever
tell those two aparts based on IKE.

> The following are just minor syntax errors which I noticed;
>
> 'The KEv2 Authentication Method value for the NULL Authentication' -
> missing 'I' ?
>
> 'Un-authenticated IKE sessions MUST only attempted when authenticated' -
> 'MUST only be attempted' ?

Thanks, we will fix those in the next version.

> I have seen Paul's email from this afternoon which covers everything I was
> trying to say (and more!). My personal feeling is that a new session being
> authenticated should not initiate a liveness check on ALL connected peers.
> I feel that the liveness check should be performed on an idle time (or
> Pauls idea of only checking the same IP address), otherwise an attacker
> would know when they connect then the headend sends a liveness check to
> all connected peers, if you had a headend serving many 1000s of peers this
> is an easy amplification attack.

And as Valery said, if your IKE SA shows activity (or perhaps even if
the IPsec SA shows activity on the inbound SA) why not skip the liveness
check for those peers, even if those are using the same IP.

I found it interesting that Valery and I think quite differently about
liveness. I always think of it as something to do on idle peers to see
if they didn't vanish. Valery thinks there is no point sending a
liveness check on an idle peer if you don't have any traffic anyway.

It all comes down to which resources you are protecting. If you have
enough memory, Valery's approach is valid, don't bother with sending
liveness packets because the IKE SA and IPsec SA are just a few bytes
of lingering data. Not worth sending (encrypted) network traffic for.
But if the host is getting too many IKE/IPsec SAs, those might be
worth poking to clean up.

Paul

---

From: Sean Turner <[email-masked]>
Date: Thu, 22 Jan 2015 16:57:36 -0500

> I certainly hope we can get thorough reviews from the people who supported its adoption as a WG item, but the WG would also benefit from anyone else doing a review as well. Please send all comments…

Just a nit:

s2.1: r/The KEv2 Authentication Method/The IKEv2 Authentication Method/

spt

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Fri, 23 Jan 2015 16:28:20 +0000

Hi Paul

Sorry for the late reply. Hopefully the following is more clear?

When designing systems which will provide connectivity for
non-authenticated users, the system SHOULD be designed with the capacity
to support not only the maximum intended number of peers, but also include
an additional number of sessions which are created due to malicious or
erroneous behaviour. This safety margin will allow a system to still
operate safely under load until it is exceeded.

---

From: Paul Koning <[email-masked]>
Date: Fri, 23 Jan 2015 11:50:06 -0500

> On Jan 23, 2015, at 11:28 AM, Graham Bartlett (grbartle) <[email-masked]> wrote:
> 
> Hi Paul
> 
> 

I understand the sentiment, but this seems like a recommendation that can’t be tested and can’t really be implemented either.  The trouble is that the number of malicious sessions is unbounded (and may be quite large in a DOS scenario).

It might be better simply to point out the limitations of the machinery: because authentication is not provided in this case, the receiving system has no way to distinguish legitimate peers from malicious ones.  As a result, a denial of service attack may prevent the intended number of legitimate peers from communicating.  Additional session (SA?) capacity may help in such cases.

My point is that this is definitely going to be a case of throwing some more resources at the problem in the hopes it’s enough, but no way to predict whether it’s good enough.  Because of that, “SHOULD” seems inappropriate, and a simple statement of the issue and the limitations of this new protocol is better.

	paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 23 Jan 2015 12:21:51 -0500 (EST)

> My point is that this is definitely going to be a case of throwing some more resources at the problem in the hopes it’s enough, but no way to predict whether it’s good enough.  Because of that, “SH…

There are two cases of overload. A "legitimate" overload by simply having
too many (anonymous) clients, and an overload by malicious clients. It
is hard to tell the difference without authentication.

We could introduce a new notification payload for IKE_INIT that
pre-announces the desire for unauthenticated IKE. A server could then
reject/drop those connections when the load of legitimate clients gets
too high without needing to create more state. If later in the exchange
an attempt for authenticated IKE is made, the connection can be dropped
as malicious. I'm not sure if this will turn out to be a needed feature
to help with the legitimate client overload problem, so I'm tempted to
postpone adding this until we have field reports that it could be
useful.

Currently what we (libreswan) are implementing is counting both halfopen
SAs as well as states associated with unauthenticated IKE SA's. The
halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed
source ip packet could have caused our end to initiate an IKE_INIT.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 25 Jan 2015 22:09:58 +0200

I would suggest to mention DDOS in this document briefly, but to move 
the discussion (maybe add an entire section) to our dedicated 
DDOS/puzzles document. For the simple reason that we want to publish the 
NULL Auth document sooner.

Since Valery is co-author on both, I guess he gets to write it :-)

Thanks,
	Yaron

On 01/23/2015 07:21 PM, Paul Wouters wrote:
>> I understand the sentiment, but this seems like a recommendation that
>> can’t be tested and can’t really be implemented either.  The trouble
>> is that the number of malicious sessions is unbounded (and may be
>> quite large in a DOS scenario).
>>
>> It might be better simply to point out the limitations of the
>> machinery: because authentication is not provided in this case, the
>> receiving system has no way to distinguish legitimate peers from
>> malicious ones.  As a result, a denial of service attack may prevent
>> the intended number of legitimate peers from communicating.
>> Additional session (SA?) capacity may help in such cases.
>>
>> My point is that this is definitely going to be a case of throwing
>> some more resources at the problem in the hopes it’s enough, but no
>> way to predict whether it’s good enough.  Because of that, “SHOULD”
>> seems inappropriate, and a simple statement of the issue and the
>> limitations of this new protocol is better.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 26 Jan 2015 14:37:40 +0300

Hi Yaron,

there is already Section 3.2, which discusses possible
impact of NULL Auth on DOS resistance, and
the ddos/puzzles document is already referenced there.
Do you think more words need to be added to this section?

Regards,
Valery.

----- Original Message ----- 
From: "Yaron Sheffer" <[email-masked]>
To: "Paul Wouters" <[email-masked]>; "Paul Koning" <[email-masked]>
Cc: <[email-masked]>; "Graham Bartlett (grbartle)" <[email-masked]>
Sent: Sunday, January 25, 2015 11:09 PM
Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in 
IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth

Thanks,
Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 26 Jan 2015 15:35:49 +0200

Hi Valery,

The DoS/puzzles document presents a "plan" for DDoS defense. I believe 
that unauthenticated clients need to be considered as part of this plan. 
I'm OK with the general guidelines in Sec. 3.2, but suggest that the 
DDoS document needs to be beefed up to account for this use case.

Thanks,
	Yaron

On 01/26/2015 01:37 PM, Valery Smyslov wrote:
> ----- Original Message ----- From: "Yaron Sheffer" <[email-masked]>