Subject: [IPsec] New I-D on IKEv3

From: "Dan Harkins" <[email-masked]>
Date: Fri, 12 Oct 2012 16:02:20 -0700 (PDT)

Hello,

  I just submitted a new I-D that defines version 3 of IKE. The goals of
this draft are to make a more easily understood, and simpler protocol
that has a high degree of probability of achieving interoperability. It
should be easier to read, easier to understand, and easier to implement.
To those ends it:

  - severely limits the negotiable parameters and options
  - no long-term IKE SA, it's one and done
  - has a simple state machine which, if followed, should ensure the
     implementation interoperates with other implementations
  - is a true peer-to-peer protocol

  Please take a look and send me your comments! If you plan on
implementing this protocol then definitely contact me, I want to
interoperate with you.

  regards,

  Dan.

-----------------------------------------------------------

    Filename:	 draft-harkins-ikev3
    Revision:	 00
    Title:		 The (Real) Internet Key Exchange
    Creation date:	 2012-10-12
    WG ID:		 Individual Submission
    Number of pages: 41
    URL:            
http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt
    Status:          http://datatracker.ietf.org/doc/draft-harkins-ikev3
    Htmlized:        http://tools.ietf.org/html/draft-harkins-ikev3-00

---

From: Paul Wouters <[email-masked]>
Date: Sat, 13 Oct 2012 17:35:51 -0400 (EDT)

On Fri, 12 Oct 2012, Dan Harkins wrote:

> Subject: [IPsec] New I-D on IKEv3

Some remarks

- stateless IKE

I like not dealing with lingering IKE SA's, but how to tell if a
connection is dead? idletime on the IPsec SA? How to do DPD?

When a roadwarrior pops up at IP A, and then at IP B, etc, how do
we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely
and don't care about SRC/DST of the ESP packets and just send answers
the the latest IP-port we saw?

- "Only one instance of the IKEv3 protocol SHALL be run at time between
    any two peers."

What about NAT, I guess you do mean "peers" and not "IPs" but can we
always tell?

- algorithm selection

The responder can look at the initiator SPI and match up its SPI lower
bits to give its own proposal a slight edge. Could that be problematic?

- ID_BLOB_ID

I like this! And already have a use for it

- "and two Traffic Selector payloads (TS)"

In IKEv2 and here I always found it very confusing to talk about
"Traffic Selector payload" payload and the "Traffic Selector" payload.
There should really be better terms for that.

- I'm still not a fan of narrowing, see my earlier comments on ipsecme.
   It destroys the concept of a tunnel being "up" or "down". If you
   insist on narrowing, clearly state what should happen for traffic
   selectors outside the narrowed set, DROPed or ACCEPTed plaintext?
   Related: all the IKEv2 text about meaning of the first and second TS
   payload is missing (eg the src/dst of the trigger and the src/dst of
   the negiating SA). Was that intentional?

- Why still support AH?

- What happened to NAT Traversal negotiation? back to vendorids?

- Should compression be disallowed?

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Oct 2012 12:25:59 -0500

>   the negiating SA). Was that intentional?

There's been some discussion of this and I don't think tunnel state is
that simple a concept even w/o SA narrowing.  Quite aside from that
there are non-VPN use cases for narrowing SAs, so I'd like that to
remain.

> - Why still support AH?

Indeed, just remove AH.

> - Should compression be disallowed?

Or at least NOT RECOMMENDED.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 16 Oct 2012 00:37:23 -0700 (PDT)

Hi Paul,

> connection is dead? idletime on the IPsec SA? How to do DPD?

  That's a great question. There's alot of complexity that gets added
for IKE to deal with DPD and I'd just like to punt that to something
else. Idletime on the IPsec SAs is probably the way to do it.

> the the latest IP-port we saw?

  I think any stale SA would be cleaned up by the "something else" I
referred to above. Figuring out where to send packets may require
some linkage between outer and inner addresses when they get plumbed
into the kernel that would orphan an "old" IPsec SA (and possibly
facilitate it's cleanup).

  Which reminds me, one thing missing from IKEv3 is a "config mode".
That really needs to be there.

> What about NAT, I guess you do mean "peers" and not "IPs" but can we

  NAT detection is another thing I left out in my rush to hit the -00
cutoff date. I mean "peers" and the way we can tell is to include a
"this is what I think my address is" payload. The recipient can then
tell whether the other side is behind a NAT and disambiguate multiple
"peers" behind the same IP address to enforce the "only one instance"
requirement.

> bits to give its own proposal a slight edge. Could that be problematic?

  The tie is only the case where both sides initiate simultaneously and
that happens when neither side has seen the other's offer. There
just needs to be some way to unambiguously converge on accepted
parameters.

  Of course, an implementation can receive the other side's offer and
respond as if it did not (make a tie that it will win) but a responder will
always have a slight edge because he gets to see the initiator's offer
before exposing his own. Provided that they converge on acceptable
parameters, is this a problem?

>    the negiating SA). Was that intentional?

  It was not intentional to lose important information, it's just that
that section is kind of verbose and I think can be stated more succinctly.
If the IKEv3 text is missing important information, I will try to clean it
up.

> - Why still support AH?

  I have no love of AH but is it up to the key exchange protocol to
kill off an IPsec protocol?

> - What happened to NAT Traversal negotiation? back to vendorids?

  It will be in -01.

> - Should compression be disallowed?

  I am agnostic on the subject and willing to follow the will of the
group.

  Thanks alot for your comments; much appreciated.

  regards,

  Dan.

---

From: "David Brownhill (dbrownhi)" <[email-masked]>
Date: Wed, 17 Oct 2012 18:36:17 +0000

Hi Dan,

The lack or EAP authentication would be a non-starter for us to implement this in our remote access VPN client.  Why not support EAP authentication?

Regards,
David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Friday, October 12, 2012 7:02 PM
To: [email-masked]
Subject: [IPsec] New I-D on IKEv3

  Hello,

  I just submitted a new I-D that defines version 3 of IKE. The goals of this draft are to make a more easily understood, and simpler protocol that has a high degree of probability of achieving interoperability. It should be easier to read, easier to understand, and easier to implement.
To those ends it:

  Please take a look and send me your comments! If you plan on implementing this protocol then definitely contact me, I want to interoperate with you.

  regards,

  Dan.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Oct 2012 20:52:21 +0200

Add a CFG payload to the list.

By the time we add all the things that we feel must be in an IKEv3, would it be any simpler than IKEv2?

Yoav

On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote:

> Scanned by Check Point Total Security Gateway.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 17 Oct 2012 17:26:45 -0700 (PDT)

Hi David,

On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote:
> Hi Dan,
>
> The lack or EAP authentication would be a non-starter for us to implement
> this in our remote access VPN client.  Why not support EAP authentication?

  What credential are you interested in using with EAP?

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 17 Oct 2012 17:28:24 -0700 (PDT)

Hi Yoav,

> Add a CFG payload to the list.

  Already noted! CFG and NAT indication.

> it be any simpler than IKEv2?

  Yes, I believe so. Simpler, more clear, and easier to implement with a
high degree of interoperability.

  Dan.

>> The lack or EAP authentication would be a non-starter for us to
>> implement this in our remote access VPN client.  Why not support EAP
>> authentication?
>>
>> Regards,
>> David
>>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Oct 2012 08:18:55 +0200

>  What credential are you interested in using with EAP?

I'm not David, but with remote access VPN into an enterprise network, it's usually the passwords stored on the directory they are using. These directory servers support EAP over RADIUS or DIAMETER to the VPN gateway. The PSK method in the draft requires the VPN gateway to know the password (or a hash thereof). EAP (even EAP-dragonfly) doesn't.

Yoav

---

From: "David Brownhill (dbrownhi)" <[email-masked]>
Date: Thu, 18 Oct 2012 12:50:51 +0000

Hi Dan,

The most common credentials that our customers use are username/password (including variants such as one-time passwords) and there are others.

David

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2012 8:27 PM
To: David Brownhill (dbrownhi)
Cc: Dan Harkins; [email-masked]
Subject: RE: [IPsec] New I-D on IKEv3

  Hi David,

On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote:
> implement this in our remote access VPN client.  Why not support EAP authentication?

  Dan.

>   I just submitted a new I-D that defines version 3 of IKE. The goals 
> of this draft are to make a more easily understood, and simpler 
> protocol that has a high degree of probability of achieving 
> interoperability. It should be easier to read, easier to understand, and easier to implement.
> To those ends it:
>