Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Yes, the idea is to make it possible to leverage native ESP. Pretty much all IPv6 networks (at least commercial networks) don't do NAT. But some of them drop ESP packets. On these networks, NAT detection will say there is no NAT, and the ESP session will be established, but no traffic will flow. On Tue, Mar 26, 2024 at 6:24 PM Panwei (William) wrote: > Hi, > > I've read the draft and I think I can understand the solution part. But > please allow me to ask a stupid question about the motivation or use case, > because I'm a little confused about that. > > I feel that the problem of IPv6 ESP traverse failure, as described in the > draft and presentation slides, is because of NAT. IKEv2 already supports > the detection of NAT. After the detection of NAT, the peers can use IP + > UDP (4500) + ESP to traverse the NAT. Are there some use cases that this > existing solution doesn't work and this draft tries to solve? Or, are there > some use cases that IKEv2 fails in detecting the existence of NAT? > I can understand the advantages of native ESP described in the draft: 1) > no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this > draft target the use cases where IP + UDP + ESP and IP + ESP can both work > in the existence of NAT, and try to benefit from the native ESP? > > Regards & Thanks！ > Wei PAN (潘伟) > > > -Original Message- > > From: IPsec On Behalf Of Jen Linkova > > Sent: Thursday, February 29, 2024 11:28 PM > > To: ipsec@ietf.org > > Cc: Lorenzo Colitti ; Michael Richardson > > > > Subject: [IPsec] Fwd: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > > > -01 version shall address comments received since -00. > > The main change is that payload format is defined similarly to ICMPv6 > > echo, and the draft now updates RFC4303, so ESP packets with SPI == 7 > > or 8 and next header==59 are not considered to be dummy packets. > > > > Comments are appreciated! > > > > > > -- Forwarded message - > > From: > > Date: Fri, Mar 1, 2024 at 2:24 AM > > Subject: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > To: Jen Linkova , Lorenzo Colitti > > , Michael Richardson > > > > > > > > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt > > has been successfully submitted by Jen Linkova and posted to the IETF > > repository. > > > > Name: draft-colitti-ipsecme-esp-ping > > Revision: 01 > > Title:ESP Echo Protocol > > Date: 2024-02-29 > > Group:Individual Submission > > Pages:7 > > URL: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt > > Status: > > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ > > HTML: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping > > Diff: > > > https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping- > > 01 > > > > Abstract: > > > >This document defines an ESP echo function which can be used to > >detect whether a given network path supports IPv6 ESP packets. > > > > > > > > The IETF Secretariat > > > > > > > > > > -- > > Cheers, Jen Linkova > > > > ___ > > 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] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Michael Richardson wrote:
> I'm not sure I understand how you get this from the Problem
> Statement.
> Clearly, we need to clarify the purpose.
> It's not about detecting NAT, it's about determining if ESP will work or
> not.
> It's not about detecting or avoiding *NAT* per-se.
> We prefer not to have to encapsulate.
Please forgive my ignorance of the scenarios. My understanding is that ESP
failure is usually because of the existence of NAT.
Do you mean ESP may not work even if there is no NAT between the two IPsec
peers?
If yes, I'd like to know more about how ESP failed and in what kind of
situations ESP will fail.
> I think that you are over-estimating the competency of some operators:
> the experience with IPv6 is often not there.
> Even when it is, not all equipment vendors are equally competent at
> implementing/documenting things.
Is this problem, i.e., IKE works but ESP doesn't work, only exist in the IPv6
network? Does IPv4 network have the same problem?
> Imagine a situation where IPsec will be used in a (sub)site to site
> configuration. For instance, between a billing system and an
> outsourced credit card processor. {Not replacing TLS, but in addition to}
> The administrators of the billing system request "IPsec" from their
> (inhouse) network operator, and the operator looks up their howto list,
> and enables UDP port 500 and 4500, because that's what IPv4 wanted.
> Now the billing system people wonder why the it seems to work, but in
> fact no traffic gets through. It can be very hard to debug.
I have two questions here.
First, what kind of reasons (except of NAT) will cause that no traffic gets
through?
Second, will UDP encapsulated ESP get through in these circumstances?
> The purpose of this protocol is to allow that debugging.
> The network operator people, who are not allowed into the billing
> system, can instead use an ESPping utility to send ESP traffic, adjusting
> their firewalls until they understand that UDP!=ESP.
When you find out that the IKEv2 negotiation succeeds but ESP traffic can't get
through, what more information will you get from sending the ESPping and not
receiving a response?
How does this draft help the adjustments and what kind of adjustments will be
performed?
> We also realized that one can write/modify traceroute to use ESPping
> to determine how far ESP actually gets.
This sounds useful.
Regards & Thanks！
Wei PAN (潘伟)
> There are also situations where there are ECMP routers in the way which
> simply do not know what to do with ESP. A network operator could
> introduce such a sytem into a previously working site-to-site VPN and
> suddenly things stop working, or get poor performance.
>
> --
> Michael Richardson , Sandelman Software
> Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Panwei (William) wrote:
> I feel that the problem of IPv6 ESP traverse failure, as described in
> the draft and presentation slides, is because of NAT. IKEv2 already
I'm not sure I understand how you get this from the Problem Statement.
Clearly, we need to clarify the purpose.
It's not about detecting NAT, it's about determining if ESP will work or not.
> supports the detection of NAT. After the detection of NAT, the peers
> can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use
> cases that this existing solution doesn't work and this draft tries to
> solve? Or, are there some use cases that IKEv2 fails in detecting the
> existence of NAT?
It's not about detecting or avoiding *NAT* per-se.
We prefer not to have to encapsulate.
I think that you are over-estimating the competency of some operators: the
experience with IPv6 is often not there. Even when it is, not all equipment
vendors are equally competent at implementing/documenting things.
Imagine a situation where IPsec will be used in a (sub)site to site
configuration. For instance, between a billing system and an outsourced
credit card processor. {Not replacing TLS, but in addition to}
The administrators of the billing system request "IPsec" from their (inhouse)
network operator, and the operator looks up their howto list, and enables UDP
port 500 and 4500, because that's what IPv4 wanted.
Now the billing system people wonder why the it seems to work, but in fact no
traffic gets through. It can be very hard to debug.
The purpose of this protocol is to allow that debugging.
The network operator people, who are not allowed into the billing system, can
instead use an ESPping utility to send ESP traffic, adjusting their firewalls
until they understand that UDP!=ESP.
We also realized that one can write/modify traceroute to use ESPping to
determine how far ESP actually gets.
There are also situations where there are ECMP routers in the way which
simply do not know what to do with ESP. A network operator could introduce
such a sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
Hi, I've read the draft and I think I can understand the solution part. But please allow me to ask a stupid question about the motivation or use case, because I'm a little confused about that. I feel that the problem of IPv6 ESP traverse failure, as described in the draft and presentation slides, is because of NAT. IKEv2 already supports the detection of NAT. After the detection of NAT, the peers can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use cases that this existing solution doesn't work and this draft tries to solve? Or, are there some use cases that IKEv2 fails in detecting the existence of NAT? I can understand the advantages of native ESP described in the draft: 1) no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this draft target the use cases where IP + UDP + ESP and IP + ESP can both work in the existence of NAT, and try to benefit from the native ESP? Regards & Thanks！ Wei PAN (潘伟) > -Original Message- > From: IPsec On Behalf Of Jen Linkova > Sent: Thursday, February 29, 2024 11:28 PM > To: ipsec@ietf.org > Cc: Lorenzo Colitti ; Michael Richardson > > Subject: [IPsec] Fwd: New Version Notification for > draft-colitti-ipsecme-esp-ping-01.txt > > -01 version shall address comments received since -00. > The main change is that payload format is defined similarly to ICMPv6 > echo, and the draft now updates RFC4303, so ESP packets with SPI == 7 > or 8 and next header==59 are not considered to be dummy packets. > > Comments are appreciated! > > > -- Forwarded message - > From: > Date: Fri, Mar 1, 2024 at 2:24 AM > Subject: New Version Notification for > draft-colitti-ipsecme-esp-ping-01.txt > To: Jen Linkova , Lorenzo Colitti > , Michael Richardson > > > > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt > has been successfully submitted by Jen Linkova and posted to the IETF > repository. > > Name: draft-colitti-ipsecme-esp-ping > Revision: 01 > Title:ESP Echo Protocol > Date: 2024-02-29 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt > Status: > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ > HTML: > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping- > 01 > > Abstract: > >This document defines an ESP echo function which can be used to >detect whether a given network path supports IPv6 ESP packets. > > > > The IETF Secretariat > > > > > -- > Cheers, Jen Linkova > > ___ > 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
