Hi Linda, > 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"?
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 > Authentication? 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. > Thanks, Linda > > > > -----Original Message----- > From: Paul Wouters <p...@nohats.ca> > Sent: Monday, May 18, 2020 1:52 PM > To: Linda Dunbar <linda.dun...@futurewei.com> > Cc: ipsec@ietf.org WG <ipsec@ietf.org> > 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. > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > atracker.ietf.org%2Fdoc%2Fdraft-smyslov-ipsecme-ikev2-auth- > announce%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C > 1a29cf55dab94e9d7e3b08d7fb5c9754%7C0fee8ff2a3b240189c753a1d5591f > edc%7C1%7C0%7C637254247407162655&sdata=8%2B%2FxIlUKattjsk9 > 57tdKCXR137ntP8WZ5YcnNsBzBD4%3D&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. > > NHRP (using opennhrp) seems somewhat popular too? > > 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
