Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 May 2020 17:12:47 +0000

We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers (primarily Gateway) to communicate directly using IPsec to protect the traffic between them.

Is there any drafts describing the solutions to the problems identified by RFC7018?

Thank you very much,

Linda Dunbar

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 18 May 2020 17:15:49 +0000

Hi Linda,

We published the following draft for AutoDiscovery VPN. It is already implemented by Juniper and other major vendors.

https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03

Thanks,
Praveen
________________________________
From: IPsec <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Sent: Monday, May 18, 2020 10:12 AM
To: [email-masked] WG <[email-masked]>
Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

[External Email. Be cautious of content]

Thank you very much,

Linda Dunbar

Juniper Business Use Only

---

From: "vishwas.ietf" <[email-masked]>
Date: Mon, 18 May 2020 10:31:45 -0700

Linda,There were 4 drafts written based on the existing state of art at that time.We created one as HP and H3C about 6 years back. Cisco had one too and so did others.https://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02-Vishwas
-------- Original message --------From: Linda Dunbar <[email-masked]> Date: 5/18/20  10:13 AM  (GMT-08:00) To: "[email-masked] WG" <[email-masked]> Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements? 

We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers (primarily Gateway) to communicate directly using IPsec to protect the
 traffic between them. 

Thank you very much, 
 
Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 May 2020 17:53:31 +0000

Vishwas,

Thank you very much for the link.   The draft was dated aug 2013.
Why it didn’t move forward?

Linda

From: vishwas.ietf <[email-masked]>
Sent: Monday, May 18, 2020 12:32 PM
To: Linda Dunbar <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: RE: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

Linda,

There were 4 drafts written based on the existing state of art at that time.

We created one as HP and H3C about 6 years back. Cisco had one too and so did others.
https://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02

-Vishwas

-------- Original message --------
From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: 5/18/20 10:13 AM (GMT-08:00)
To: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

Thank you very much,

Linda Dunbar

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 May 2020 14:52:14 -0400 (EDT)

On Mon, 18 May 2020, Linda Dunbar wrote:

> We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers
> (primarily Gateway) to communicate directly using IPsec to protect the traffic between them.

unfortunately, standarization failed because vendors wanted their own
solution standarized, and the WG didn't want multiple standards, so
it decided to do none.

For libreswan, we do "Opportunistic IPsec", which is basically "just try
host-to-host IPsec, fail to either clear or block depending on policy".
We also have a "you can do auth-null for passive attack protection"
in one or both directions" and a migration path from there to fully
authenticated IPsec. Authentication based on a shared CA or DNSSEC.

These are packet trigger based solutions.

It works well for most meshes, and requires no proprietary or new
standards. The only two non-standard parts are that when using
certificates, we allow requiring an addictional call to match
the IKE ID with certificate SAN in the DNS (to prevent a compromised
node from pretending to be another node in the mesh) and we have
one non-standarized payload to signify we can do auth-null as well as
authenticated IPsec, which we hopefully can retire once this document
gets adopted / implemented:

https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-auth-announce/

> Is there any drafts describing the solutions to the problems identified by RFC7018?

There might be the old drafts of the autovpn candidates, but as that is
all incompatible and/or proprietary, and mostly from before my time, I
have not looked at those solutions much.

One issue I have with Cisco solutions, is that they now prefer to wrap
everything in GRE, which isn't the best from a security point of view.

NHRP (using opennhrp) seems somewhat popular too?

Paul

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 20 May 2020 17:34:00 +0000

Paul, 

Thank you very much for the detailed explanation. 

What is " you can do auth-null for passive attack protection"?  does it mean "NO Authentication"? 
If two peers have shared CA, does it mean there is no need for Authentication? 

Thanks, Linda

-----Original Message-----
From: Paul Wouters <[email-masked]> 
Sent: Monday, May 18, 2020 1:52 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018 Auto-Discovery VPN Problem Statement and Requirements?

On Mon, 18 May 2020, Linda Dunbar wrote:

> We are experiencing the problems described in RFC 7018 (Auto-Discovery 
> VPN Problem Statement and Requirements), i.e. the  problem of enabling a large number of peers (primarily Gateway) to communicate directly using IPsec to protect the traffic between them.

unfortunately, standarization failed because vendors wanted their own solution standarized, and the WG didn't want multiple standards, so it decided to do none.

For libreswan, we do "Opportunistic IPsec", which is basically "just try host-to-host IPsec, fail to either clear or block depending on policy".
We also have a "you can do auth-null for passive attack protection"
in one or both directions" and a migration path from there to fully authenticated IPsec. Authentication based on a shared CA or DNSSEC.

It works well for most meshes, and requires no proprietary or new standards. The only two non-standard parts are that when using certificates, we allow requiring an addictional call to match the IKE ID with certificate SAN in the DNS (to prevent a compromised node from pretending to be another node in the mesh) and we have one non-standarized payload to signify we can do auth-null as well as authenticated IPsec, which we hopefully can retire once this document gets adopted / implemented:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-smyslov-ipsecme-ikev2-auth-announce%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1a29cf55dab94e9d7e3b08d7fb5c9754%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637254247407162655&amp;sdata=8%2B%2FxIlUKattjsk957tdKCXR137ntP8WZ5YcnNsBzBD4%3D&amp;reserved=0

> Is there any drafts describing the solutions to the problems identified by RFC7018?

There might be the old drafts of the autovpn candidates, but as that is all incompatible and/or proprietary, and mostly from before my time, I have not looked at those solutions much.

One issue I have with Cisco solutions, is that they now prefer to wrap everything in GRE, which isn't the best from a security point of view.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 24 May 2020 19:23:58 +0300

Hi Linda,

> What is " you can do auth-null for passive attack protection"?  does it
mean
> "NO Authentication"?

Yes, NULL authentication method in IKEv2 provides
no authentication. It is intended to be used in cases where
no trust relationship exists between peers or where authentication is 
performed by other means. It only protects against passive attacks.

> If two peers have shared CA, does it mean there is no need for

If peers have shared CA they can mutually authenticate themselves
and there is no need for NULL authentication in this case.

Hope this helps,
Valery.

> Subject: Re: [IPsec] Is there any drafts or RFCs on solutions to RFC 7018
> Auto-Discovery VPN Problem Statement and Requirements?
> 
> > VPN Problem Statement and Requirements), i.e. the  problem of enabling
> a large number of peers (primarily Gateway) to communicate directly using
> IPsec to protect the traffic between them.
> 
> solution standarized, and the WG didn't want multiple standards, so it
> decided to do none.
> 
host-
> to-host IPsec, fail to either clear or block depending on policy".
> standards.. The only two non-standard parts are that when using
> certificates, we allow requiring an addictional call to match the IKE ID
with
> certificate SAN in the DNS (to prevent a compromised node from pretending
> to be another node in the mesh) and we have one non-standarized payload
> to signify we can do auth-null as well as authenticated IPsec, which we
> hopefully can retire once this document gets adopted / implemented:
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fdraft-smyslov-ipsecme-ikev2-auth-
> announce%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C
> 1a29cf55dab94e9d7e3b08d7fb5c9754%7C0fee8ff2a3b240189c753a1d5591f
> edc%7C1%7C0%7C637254247407162655&amp;sdata=8%2B%2FxIlUKattjsk9
> 57tdKCXR137ntP8WZ5YcnNsBzBD4%3D&amp;reserved=0
> 
> > Is there any drafts describing the solutions to the problems identified
by
> RFC7018?
all
> incompatible and/or proprietary, and mostly from before my time, I have
> not looked at those solutions much.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec