Re: [IPsec] Does ESP provide all functionality offered by AH?
On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote: > Dear all, > > I am writing this as I have a question that I've failed to clarify by > other means. > > It is commonly stated that the ESP protocol covers all of the > functionality afforded by AH (integrity and authentication) in > addition to confidentiality, with the exception that AH also protects > the parts of the IP header that are nonmutable in transit (the source > and destination fields most notably). This is then used as leverage in > the argument to justify the need of applying two SAs to a single > traffic pattern (i.e. connection): "ESP for authentication, integrity > and confidentiality. AH for protecting the source and IP address". It > should be noted that this only applies to transport mode as the whole > "tunneled" IP packet can be protected by ESP while in tunnel mode. > > However, RFC 4301 stipulates that after AH / ESP processing the > addressing information of the packet must be successfully matched with > the traffic pattern of the associated SAD entry. In my eyes, this > would make it impossible for an attacker to alter (most importantly) > the source address of a packet as it would be discarded. > > From page 62, RFC 4301: > > ... > 4. Apply AH or ESP processing as specified, using the SAD entry >selected in step 3a above. Then match the packet against the >inbound selectors identified by the SAD entry to verify that the >received packet is appropriate for the SA via which it was >received. > ... > > This, if true, would imply that all functionality offered by AH could > be provided by ESP. Is this true? The only "loopholes" I could come up > with is the case of extension headers in IPv6 which are not protected > by ESP, or issues arising in conjunction with multicast. > > In any case, I would be very happy if someone could clarify this > question for me. > The notion of discarding AH entirely has been discussed for many years. I've long been in favor of it, though I can't find a copy of anything old I had posted in my mail archives at the moment. The counter-argument -- and again, it's been presented many times over many years -- is that AH protects some IP options. That's useless in IPv4; the assertion is that it's important in IPv6. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
On 15 Nov 2011, at 12:46, Scott Fluhrer (sfluhrer) wrote: > > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Frederic Detienne >> Sent: Monday, November 14, 2011 8:52 PM >> To: Paul Wouters >> Cc: ipsec@ietf.org; Yoav Nir; Vilhelm Jutvik >> Subject: Re: [IPsec] Does ESP provide all functionality offered by AH? >> >> >> Can you please explain your point about transport mode being bad ? We >> do not see any problem with it in real world deployments. It is quite >> the opposite actually. >> >> I agree that AH is a hindrance, especially that it protects the non- >> mutable fields of the IP header and therefor prevents NAT and ToS re- >> marking. > > One minor correction: the DSCP field is mutable, and hence ToS remarking > is not a problem. you are right. Thanks for the correction! :-) fred >> I.e. the main difference between AH and ESP_NULL is really >> this outer IP header protection which is detrimental in most practical >> networks. >> > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Hi Mark I see that you're not at the IETF. Will you be following the meeting through Jabber and (hopefully) audio? Anyway, GRE and NHRP are standardized protocols that could be used as part of a large scale solution. I don't (personally) believe that they are as scalable as other solutions we might propose, but they should not be dismissed. Regardless of their optimality, they do not cover some of the requirements: - to find out what is accessible through VPN as opposed to not through VPN - to provision credentials for authentication between two IKE hosts And once we go to a large-scale scenario like you describe with multiple administrative domains, you have to deal with the trust issue, and that's a big one. The current IKE and IPsec RFCs do not deal with cross-domain trust. Yoav On Nov 15, 2011, at 12:29 PM, Mark Boltz wrote: > With all due respect to Cisco, the larger problem we're trying to address, is > in part the fact that DMVPN and ACVPN are vendor specific implementations. > And the goal of the implementation we're seeking is *large scale* P2P VPNs. > > In other words, VPNs that cannot, or better put, MUST not assume that all > equipment is from a single vendor. And we're not talking about the order of > 100, 500 or even necessarily 1,000 gateways or end points. > > Picture a hypothetical where a larger interest desires an IPsec VPN, in, say > the airline industry. We're talking about several thousand aircraft from > several manufacturers. All in motion, trying to communicate to the nearest > local ground station. Said ground station is perhaps an ATC, which are run by > the FAA (Cleveland Center, Potomac Approach, etc) of which there are also > thousands globally. The aircraft are also communicating with airports, which > are also typically regionally controlled (Washington Metro Area Airports > Authority, Port Authority of NY/NJ, etc.). And each of those aircraft are > also property of tens of global carriers. > > Each has its own IT infrastructure. Each can be said to have some marginal > level of trust between them, but likely not on the same level. > > Each has VPN gateways that are representative, among the collective several > 1,000 to even 10,000 from at least, oh say 14 different vendors. > > Explain to me how the earlier discussion of DNSSEC, or any other supposed, " > but we already have a solution" addresses that type of "large-scale, P2P > VPN". And please do so in a standards-based, non-proprietary way, that > accommodates 10,000+ gateways, independent of vendors, and won't take me 10 > years to configure. > > -- > Mark Boltz, CISSP, CISA, NSA-IEM, CSGI > Director, Federal and Mid-Atlantic > e: mark.bo...@stonesoft.com e: fede...@stonesoft.com > p: 866.869.4075 c: 571.246.2233 > o: 202.434.8963 f: 202.318.2333 > w: http://www.stonesoft.com > > 1200 G St. NW, Suite 800 > Washington, DC 20005-6705 > > Stonesoft: Network Security. Simplified. > > On Nov 14, 2011, at 10:43 PM, "Frederic Detienne" wrote: > >> >> At this stage, I would like to go back to the basics. >> >> At least two vendors already provide NHRP/GRE/IPsec to address what seems to >> relate to the peer discovery part of the problem statement. Cisco calls it >> DMVPN and Juniper calls it ACVPN. >> >> Based on your wording so far, everything I read you want seems actually >> already covered in existing solutions (speaking for DMVPN in particular). >> >> Can you please explain what does not suit you in these solutions ? How do >> these not meet your requirements ? Understanding the gaps will save everyone >> a lot of time. >> >> I really would like you to cover the issues in terms that are NOT what you >> want (which is too vague) but specifically how DMVPN do not suit you. >> >> thanks, >> >> fred >> >> >> On 08 Nov 2011, at 18:44, Ulliott, Chris wrote: >> >>> In my use case, there may be multiple Hubs, each with their own spokes and >>> each hub will (probably) by managed by different providers. Spokes from >>> different hubs will need to communicate with each other, but policy will be >>> needed to determine which spokes they are permitted to communicate with >>> (_not_ specified by IP address though - but something more logical, such as >>> organisation or function for example, Org A is willing to communicate >>> with all spokes run by org B) >>> >>> Chris >>> >>> >>> -Original Message- >>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of >>> Praveen Sathyanarayan >>> Sent: Monday, November 07, 2011 5:10 PM >>> To: bill manning; Geoffrey Huang >>> Cc: ipsec@ietf.org >>> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem >>> >>> There was offline discussion about P2P offered by Juniper Networks (we >>> believe Cisco has similar approach, called DMVPN) SSG product line. I am >>> forwarding this email to group. >>> >>> In nutshell: >>> >>> Site to site tunnel -
Re: [IPsec] Does ESP provide all functionality offered by AH?
> -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Frederic Detienne > Sent: Monday, November 14, 2011 8:52 PM > To: Paul Wouters > Cc: ipsec@ietf.org; Yoav Nir; Vilhelm Jutvik > Subject: Re: [IPsec] Does ESP provide all functionality offered by AH? > > > Can you please explain your point about transport mode being bad ? We > do not see any problem with it in real world deployments. It is quite > the opposite actually. > > I agree that AH is a hindrance, especially that it protects the non- > mutable fields of the IP header and therefor prevents NAT and ToS re- > marking. One minor correction: the DSCP field is mutable, and hence ToS remarking is not a problem. > I.e. the main difference between AH and ESP_NULL is really > this outer IP header protection which is detrimental in most practical > networks. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
With all due respect to Cisco, the larger problem we're trying to address, is in part the fact that DMVPN and ACVPN are vendor specific implementations. And the goal of the implementation we're seeking is *large scale* P2P VPNs. In other words, VPNs that cannot, or better put, MUST not assume that all equipment is from a single vendor. And we're not talking about the order of 100, 500 or even necessarily 1,000 gateways or end points. Picture a hypothetical where a larger interest desires an IPsec VPN, in, say the airline industry. We're talking about several thousand aircraft from several manufacturers. All in motion, trying to communicate to the nearest local ground station. Said ground station is perhaps an ATC, which are run by the FAA (Cleveland Center, Potomac Approach, etc) of which there are also thousands globally. The aircraft are also communicating with airports, which are also typically regionally controlled (Washington Metro Area Airports Authority, Port Authority of NY/NJ, etc.). And each of those aircraft are also property of tens of global carriers. Each has its own IT infrastructure. Each can be said to have some marginal level of trust between them, but likely not on the same level. Each has VPN gateways that are representative, among the collective several 1,000 to even 10,000 from at least, oh say 14 different vendors. Explain to me how the earlier discussion of DNSSEC, or any other supposed, " but we already have a solution" addresses that type of "large-scale, P2P VPN". And please do so in a standards-based, non-proprietary way, that accommodates 10,000+ gateways, independent of vendors, and won't take me 10 years to configure. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.bo...@stonesoft.com e: fede...@stonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 202.318.2333 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Nov 14, 2011, at 10:43 PM, "Frederic Detienne" wrote: > > At this stage, I would like to go back to the basics. > > At least two vendors already provide NHRP/GRE/IPsec to address what seems to > relate to the peer discovery part of the problem statement. Cisco calls it > DMVPN and Juniper calls it ACVPN. > > Based on your wording so far, everything I read you want seems actually > already covered in existing solutions (speaking for DMVPN in particular). > > Can you please explain what does not suit you in these solutions ? How do > these not meet your requirements ? Understanding the gaps will save everyone > a lot of time. > > I really would like you to cover the issues in terms that are NOT what you > want (which is too vague) but specifically how DMVPN do not suit you. > > thanks, > >fred > > > On 08 Nov 2011, at 18:44, Ulliott, Chris wrote: > >> In my use case, there may be multiple Hubs, each with their own spokes and >> each hub will (probably) by managed by different providers. Spokes from >> different hubs will need to communicate with each other, but policy will be >> needed to determine which spokes they are permitted to communicate with >> (_not_ specified by IP address though - but something more logical, such as >> organisation or function for example, Org A is willing to communicate >> with all spokes run by org B) >> >> Chris >> >> >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of >> Praveen Sathyanarayan >> Sent: Monday, November 07, 2011 5:10 PM >> To: bill manning; Geoffrey Huang >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem >> >> There was offline discussion about P2P offered by Juniper Networks (we >> believe Cisco has similar approach, called DMVPN) SSG product line. I am >> forwarding this email to group. >> >> In nutshell: >> >> Site to site tunnel - >> P2P cut thru tunnel * >> >> >> + SPOKE 1 - >> Host1 >> | * >> | * >> HUB ---+ * >> | * >> | * >> + SPOKE 2-- Host2 >> >> >> >> In this solution, HUB is the trust entity that all spoke establish static >> IPSec tunnel (either using Site to site tunnel or spoke establish dynamic >> remote access tunnel with hub). When tunnel is established, spoke will >> exchange registration information, that will include network this spoke >> protects (trust/corporate network), security suite information etc. Hub >> will collect all these information all spoke. >> >> When Host 1 (in spoke1) wants to talk to particular host
Re: [IPsec] P2P VPN - Side Meeting
On 15 Nov 2011, at 12:05, Yoav Nir wrote: > Hi Frederic > > Inline... > > On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: > >> Hi Yoav, >> >> We will be there (following offline with you for the details). >> >> I do not think there is a need to spend 20 minutes on the draft which >> everyone should have read. There are three vague points in it and 10 min >> seem largely sufficient. > > 20 minutes includes time spent on hellos, introductions, asking if everyone > has read the draft, jabber scribe, testing the audio, and all other kinds of > administrivia. You've been to IETF sessions before, and you know how that > goes. absolutely. Then we agree on the 20 min. >> At this stage several vendors think they have a fair understanding of the >> requirements and a gap analysis is much more productive and constructive. I >> have just asked Chris Ulliott to provide his feedback in case audio fails on >> us. We can factor his reply in the discussions. > > To me the biggest gap in existing solutions is that they require kludges like > GRE tunnels and route-based VPN, and also that they don't cover the > provisioning of credentials. GRE tunnels and route-based VPNs I consider a > kludge because you are then required to treat VPN tunnels as interfaces. > Interfaces are much more resource intensive when compared to simple SAs, and > most operating systems are very limited in the number of interfaces that they > support. These are all very vague but generally misinformed statements. >> We will not send our presentation in advance but we will publish the >> relevant material after the meeting. The discussion following the >> presentations is likely to bring additional material to the table. > > Downloadable presentations help people who are following remotely (like > Chris) in case the audio does not fail. we can share via webex if needed. fred >> >> regards, >> >> fred > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: > Hi Yoav, > > We will be there (following offline with you for the details). > > I do not think there is a need to spend 20 minutes on the draft which > everyone should have read. There are three vague points in it and 10 min seem > largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. > At this stage several vendors think they have a fair understanding of the > requirements and a gap analysis is much more productive and constructive. I > have just asked Chris Ulliott to provide his feedback in case audio fails on > us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. > We will not send our presentation in advance but we will publish the relevant > material after the meeting. The discussion following the presentations is > likely to bring additional material to the table. Downloadable presentations help people who are following remotely (like Chris) in case the audio does not fail. > > regards, > > fred ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. We will not send our presentation in advance but we will publish the relevant material after the meeting. The discussion following the presentations is likely to bring additional material to the table. regards, fred On 14 Nov 2011, at 10:09, Yoav Nir wrote: > Hi all > > This is to announce a side meeting about peer to peer VPN, as described in > our recently published draft: > http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 > > In the meeting we will discuss the use case of directly connecting two IKE > implementations that already have a path of trust between them, for example > turning star topologies into meshes. The introduction of strangers (AKA > "opportunistic encryption") is explicitly out of scope for this meeting. > > Where: TICC building, room 101-D > When:Wednesday, 16-Nov, at 20:00 (8:00 PM) local time > Jabber: xmpp:ipse...@jabber.ietf.org?join > Streaming audio: http://ietf82streaming.dnsalias.net/ietf/ietf824.m3u > > Tentative Agenda: > - A 20-minute presentation about the draft > - 3-5 really short presentations about existing proprietary (or not) solutions > - Open discussion on the problem (which will inevitably get into solutions) > - Next Steps (this is when we ask the "who will edit/contribute/review") > > Note: > the streaming audio may or may not work. They don't switch off the audio > after hours, but you won't get support from the NOC team either. > If that fails, we'll try to make do with Skype ( > http://portal.campaigncc.org/SkypeConferencing ), but that is at best a > best-effort solution. > > 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] New -00 draft: Creating Large Scale Mesh VPNs Problem
At this stage, I would like to go back to the basics. At least two vendors already provide NHRP/GRE/IPsec to address what seems to relate to the peer discovery part of the problem statement. Cisco calls it DMVPN and Juniper calls it ACVPN. Based on your wording so far, everything I read you want seems actually already covered in existing solutions (speaking for DMVPN in particular). Can you please explain what does not suit you in these solutions ? How do these not meet your requirements ? Understanding the gaps will save everyone a lot of time. I really would like you to cover the issues in terms that are NOT what you want (which is too vague) but specifically how DMVPN do not suit you. thanks, fred On 08 Nov 2011, at 18:44, Ulliott, Chris wrote: > In my use case, there may be multiple Hubs, each with their own spokes and > each hub will (probably) by managed by different providers. Spokes from > different hubs will need to communicate with each other, but policy will be > needed to determine which spokes they are permitted to communicate with > (_not_ specified by IP address though - but something more logical, such as > organisation or function for example, Org A is willing to communicate > with all spokes run by org B) > > Chris > > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Praveen Sathyanarayan > Sent: Monday, November 07, 2011 5:10 PM > To: bill manning; Geoffrey Huang > Cc: ipsec@ietf.org > Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem > > There was offline discussion about P2P offered by Juniper Networks (we > believe Cisco has similar approach, called DMVPN) SSG product line. I am > forwarding this email to group. > > In nutshell: > > Site to site tunnel - > P2P cut thru tunnel * > > > + SPOKE 1 - > Host1 > | * > | * > HUB ---+ * > | * > | * > + SPOKE 2-- Host2 > > > > In this solution, HUB is the trust entity that all spoke establish static > IPSec tunnel (either using Site to site tunnel or spoke establish dynamic > remote access tunnel with hub). When tunnel is established, spoke will > exchange registration information, that will include network this spoke > protects (trust/corporate network), security suite information etc. Hub > will collect all these information all spoke. > > When Host 1 (in spoke1) wants to talk to particular host, which resides > in Host 2 (in spoke2), spoke 1 will contact Hub. Hub will do resolution > and identifies spoke2 is the right gateway to contact and then provides > PAD, SPD information about spoke2 to spoke 1. There on spoke 1 establishes > tunnel directly with Spoke 2. > > More detail about this solution can be referred below. > > Thanks, > Praveen > > > On 10/10/11 11:17 PM, "Suresh Melam" wrote: > > > It is good to see the requirements purely from the usage perspective. > Praveen and I had discussions and we want to share the current solutions > (Juniper SSG's ACVPN or Cisco DM-VPN) as they pertain to the problem we are > trying to solve. > > The problem statement I really see as > "dynamic-spoke-to-spoke-direct-secure-connectivity" > > Basically, with minimum amount of configuration, we need secure mesh > connectivity on demand. The way to acheive this is by having spokes > register > their information to the hub they are connected to. > > To begin with, each spoke needs to have atleast one static IPsec > configuration > towards one hub (may or may not be nearest). Once the tunnel is > established > with the hub, over the secure channel, spoke registers its info with the > hub. > The info may contain items like, IKE-identity, the-subnets-it-is-serving, > authentication-information-like-the-certificate-it-will-be-using etc., > With > this registration procedure, hub can maintain a database of different > spokes > and their respective information. > > Now once hub notices that two spokes are communicating with each other, via > two different tunnels towards hub, hub can inform two spokes that they may > as > well try to acheive direct connectivity. This happens via a resolution > mechanism, where hub *pushes* down the info about spoke1 to spoke2 and vice > versa. As spokes are receiving this information via a secure channel, they > treat hub as trusted source of information and relies on this information > to > negotiate a tunnel directly between themselves. Once the new dynamic > tunnel > is established, the traffic between two spokes gets re-routed smoothly to > the > new dynamic tunnel. While this resolution process and new negotiation
Re: [IPsec] Does ESP provide all functionality offered by AH?
On 15 Nov 2011, at 10:03, Nico Williams wrote: > On Mon, Nov 14, 2011 at 7:51 PM, Frederic Detienne wrote: >> Can you please explain your point about transport mode being bad ? We do not >> see any problem with it in real world deployments. It is quite the opposite >> actually. > > RFC4301, section 4.1 has some text on this, though, quite frankly, I > don't think there's any reason not to use transport mode in end-to-end > and end<->GW communications, and also, for the latter, no reason that > using an IP tunnel inside transport mode ESP shouldn't work just fine > (Dan McDonald used this approach for a VPN system at Sun Microsystems > [RIP]). Many vendors do that IP tunneling + ESP Transport and yes, this is a very fine use. This is why I questioned why "transport" was criticized. I understand the issues section 4.1 raises but these are really implementation and network design issue again. Once tunnels are being used, the whole security aspect is actually factored into the overlay network design. The whole comment there apply to a pure IPsec Security Gateway. The section would really deserve to be either deflated altogether or augmented with a use case (c) where the Security Gateway has other network and security mechanisms to meet the security requirements. >> I agree that AH is a hindrance, especially that it protects the non-mutable >> fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. >> the main difference between AH and ESP_NULL is really this outer IP header >> protection which is detrimental in most practical networks. > > Yes, this is why we all dislike AH. It will be hard to find someone to defend AH :-) I still would be happy to hear if someone has a good argument. fred > Nico > -- > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
On 15 Nov 2011, at 10:05, Paul Wouters wrote: > On Tue, 15 Nov 2011, Frederic Detienne wrote: > >> Can you please explain your point about transport mode being bad ? We do not >> see any problem with it in real world deployments. It is quite the opposite >> actually. > > I meant the kludge where transport mode (host-host) has to deal with NAT-T > where the inner IP of the client > is used, making it kinda a tunnel mode ( internalip/32-host-host) I see what you mean but we have found tunnel mode to be impractical in similar protocol suites but different scenarios. Transport turns out to be really efficient and elegant in our cases. This is really an implementation issue and vendors have to tune their codes to their customer's use cases. Additionally, there are many customers out there who really want to reclaim every possible byte. When the average clear text packet size is small, the overhead that tunnel imposes is significant. I would say that transport mode is actually very useful actually but really depends on your usage. >> I agree that AH is a hindrance, especially that it protects the non-mutable >> fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. >> the main difference between AH and ESP_NULL is really this outer IP header >> protection which is detrimental in most practical networks. > > Yes. we've seen cellphone manufacturors that use Linux specifically patching > Openswan KLIPS to allow ToS rewriting. I think most people would agree that AH is really not a good idea. :-) > Paul > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
In most contexts, there is no real benefit to using two SAs (AH + ESP) as you describe. I agree that, in almost every case, just using ESP will suffice. Using ESP in tunnel mode is certainly good enough, and less expensive than 2 SAs. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
On Tue, 15 Nov 2011, Frederic Detienne wrote: Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually. I meant the kludge where transport mode (host-host) has to deal with NAT-T where the inner IP of the client is used, making it kinda a tunnel mode ( internalip/32-host-host) I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is really this outer IP header protection which is detrimental in most practical networks. Yes. we've seen cellphone manufacturors that use Linux specifically patching Openswan KLIPS to allow ToS rewriting. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
On Mon, Nov 14, 2011 at 7:51 PM, Frederic Detienne wrote: > Can you please explain your point about transport mode being bad ? We do not > see any problem with it in real world deployments. It is quite the opposite > actually. RFC4301, section 4.1 has some text on this, though, quite frankly, I don't think there's any reason not to use transport mode in end-to-end and end<->GW communications, and also, for the latter, no reason that using an IP tunnel inside transport mode ESP shouldn't work just fine (Dan McDonald used this approach for a VPN system at Sun Microsystems [RIP]). > I agree that AH is a hindrance, especially that it protects the non-mutable > fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. > the main difference between AH and ESP_NULL is really this outer IP header > protection which is detrimental in most practical networks. Yes, this is why we all dislike AH. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
Can you please explain your point about transport mode being bad ? We do not see any problem with it in real world deployments. It is quite the opposite actually. I agree that AH is a hindrance, especially that it protects the non-mutable fields of the IP header and therefor prevents NAT and ToS re-marking. I.e. the main difference between AH and ESP_NULL is really this outer IP header protection which is detrimental in most practical networks. On 15 Nov 2011, at 08:09, Paul Wouters wrote: > On Tue, 15 Nov 2011, Yoav Nir wrote: > >> FreeS/WAN did eliminate transport mode, but that project is dead. The >> project that is active now (strongSwan) does have it. > > > > So does openswan, which is the continuation project from FreeS/WAN, and had > its most recent software > release just a few weeks ago. But we wish people would not use either > transport mode or AH. > >> RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for >> L2TP over IPsec. That, and the fact that this is the way Microsoft >> implemented their L2TP client is the reason why most gateway vendors have >> implemented transport mode. That and the fact that Cisco like to encrypt >> their GRE tunnels in transport mode. > > openswan also supports multiple L2TP clients behind the same NAT router > and multiple L2TP clients on the same overlapping pre-NAT IP address > using the KLIPS stack with SAref tracking using two new socket options and > ip_conntrack. The NETKEY builtin stack for Linux has no such capability. > > See: > > http://www.openswan.org/docs/ipsecsaref.png > https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd > https://gsoc.xelerance.com/projects/openswan/wiki/Building_and_Installing_an_SAref_capable_KLIPS_version_for_DebianUbuntu > > The same funcionality is used with Openswan to support multiple connections > with customers with > unknown RFC1918 address space that overlaps, which is common in large cloud > deployments. > > 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] Does ESP provide all functionality offered by AH?
On Tue, 15 Nov 2011, Yoav Nir wrote: FreeS/WAN did eliminate transport mode, but that project is dead. The project that is active now (strongSwan) does have it. So does openswan, which is the continuation project from FreeS/WAN, and had its most recent software release just a few weeks ago. But we wish people would not use either transport mode or AH. RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for L2TP over IPsec. That, and the fact that this is the way Microsoft implemented their L2TP client is the reason why most gateway vendors have implemented transport mode. That and the fact that Cisco like to encrypt their GRE tunnels in transport mode. openswan also supports multiple L2TP clients behind the same NAT router and multiple L2TP clients on the same overlapping pre-NAT IP address using the KLIPS stack with SAref tracking using two new socket options and ip_conntrack. The NETKEY builtin stack for Linux has no such capability. See: http://www.openswan.org/docs/ipsecsaref.png https://gsoc.xelerance.com/projects/openswan/wiki/L2TPIPsec_configuration_using_openswan_and_xl2tpd https://gsoc.xelerance.com/projects/openswan/wiki/Building_and_Installing_an_SAref_capable_KLIPS_version_for_DebianUbuntu The same funcionality is used with Openswan to support multiple connections with customers with unknown RFC1918 address space that overlaps, which is common in large cloud deployments. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
About transport mode, true enough, and see also 4891 for an IPv6 flavor. But transport mode is not the reason for AH. These things could easily have avoided transport mode. In IPv4, the place to look for different functionality with AH is to look away from unicast to multicast and perhaps anycast. Rich Graveman On Mon, Nov 14, 2011 at 5:55 PM, Yoav Nir wrote: > What Paul said, mostly, but see below. > > On Nov 15, 2011, at 2:39 AM, Paul Wouters wrote: > >> On Sun, 13 Nov 2011, Vilhelm Jutvik wrote: >> From page 62, RFC 4301: >>> >>> ... >>> 4. Apply AH or ESP processing as specified, using the SAD entry >>> selected in step 3a above. Then match the packet against the >>> inbound selectors identified by the SAD entry to verify that the >>> received packet is appropriate for the SA via which it was >>> received. >>> ... >>> >>> This, if true, would imply that all functionality offered by AH could >>> be provided by ESP. Is this true? >> >> I agree. The people who prefer transport mode usually mutter something about >> a few saved bytes and how that is better for the MTU. But tunnel mode works >> much better through NAT then transport mode, which needs ackward hacks that >> are all vendor-specific. ESP-null is basically the equivalent of AH. It has >> been about a decade now that Ferguson and Scheier said to get rid of AH and >> transport mode altogether - as a result of which FreeS/WAN 2.05 was released >> that removed support for it. >> >> See further: http://www.schneier.com/paper-ipsec.pdf > > FreeS/WAN did eliminate transport mode, but that project is dead. The project > that is active now (strongSwan) does have it. > > RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for > L2TP over IPsec. That, and the fact that this is the way Microsoft > implemented their L2TP client is the reason why most gateway vendors have > implemented transport mode. That and the fact that Cisco like to encrypt > their GRE tunnels in transport mode. > ___ > 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] Does ESP provide all functionality offered by AH?
What Paul said, mostly, but see below. On Nov 15, 2011, at 2:39 AM, Paul Wouters wrote: > On Sun, 13 Nov 2011, Vilhelm Jutvik wrote: > >>> From page 62, RFC 4301: >> >> ... >> 4. Apply AH or ESP processing as specified, using the SAD entry >> selected in step 3a above. Then match the packet against the >> inbound selectors identified by the SAD entry to verify that the >> received packet is appropriate for the SA via which it was >> received. >> ... >> >> This, if true, would imply that all functionality offered by AH could >> be provided by ESP. Is this true? > > I agree. The people who prefer transport mode usually mutter something about > a few saved bytes and how that is better for the MTU. But tunnel mode works > much better through NAT then transport mode, which needs ackward hacks that > are all vendor-specific. ESP-null is basically the equivalent of AH. It has > been about a decade now that Ferguson and Scheier said to get rid of AH and > transport mode altogether - as a result of which FreeS/WAN 2.05 was released > that removed support for it. > > See further: http://www.schneier.com/paper-ipsec.pdf FreeS/WAN did eliminate transport mode, but that project is dead. The project that is active now (strongSwan) does have it. RFC 3191 (L2TP over IPsec) says that transport mode MUST be supported for L2TP over IPsec. That, and the fact that this is the way Microsoft implemented their L2TP client is the reason why most gateway vendors have implemented transport mode. That and the fact that Cisco like to encrypt their GRE tunnels in transport mode. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
On Sun, 13 Nov 2011, Vilhelm Jutvik wrote: From page 62, RFC 4301: ... 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. ... This, if true, would imply that all functionality offered by AH could be provided by ESP. Is this true? I agree. The people who prefer transport mode usually mutter something about a few saved bytes and how that is better for the MTU. But tunnel mode works much better through NAT then transport mode, which needs ackward hacks that are all vendor-specific. ESP-null is basically the equivalent of AH. It has been about a decade now that Ferguson and Scheier said to get rid of AH and transport mode altogether - as a result of which FreeS/WAN 2.05 was released that removed support for it. See further: http://www.schneier.com/paper-ipsec.pdf Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Does ESP provide all functionality offered by AH?
Dear all, I am writing this as I have a question that I've failed to clarify by other means. It is commonly stated that the ESP protocol covers all of the functionality afforded by AH (integrity and authentication) in addition to confidentiality, with the exception that AH also protects the parts of the IP header that are nonmutable in transit (the source and destination fields most notably). This is then used as leverage in the argument to justify the need of applying two SAs to a single traffic pattern (i.e. connection): "ESP for authentication, integrity and confidentiality. AH for protecting the source and IP address". It should be noted that this only applies to transport mode as the whole "tunneled" IP packet can be protected by ESP while in tunnel mode. However, RFC 4301 stipulates that after AH / ESP processing the addressing information of the packet must be successfully matched with the traffic pattern of the associated SAD entry. In my eyes, this would make it impossible for an attacker to alter (most importantly) the source address of a packet as it would be discarded. >From page 62, RFC 4301: ... 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. ... This, if true, would imply that all functionality offered by AH could be provided by ESP. Is this true? The only "loopholes" I could come up with is the case of extension headers in IPv6 which are not protected by ESP, or issues arising in conjunction with multicast. In any case, I would be very happy if someone could clarify this question for me. Sincerely, Vilhelm Jutvik ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
