Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

[Michael Richardson <[e-mail]>]

Panwei (William) <[e-mail]> 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.

usually, a bad firewall.
One that allows UDP traffic (port 500/4500), but not proto=50.
For IPv4, there will often be NAT, so the proto=50 firewall doesn't matter,
as one has to UDP encap anyway.

    >> 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?

Yes.
It could exist in IPv4, and I've seen it, but NAT44 means you seldom notice.

    > Second, will UDP encapsulated ESP get through in these circumstances?

Probably.

    >> 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?

That there is a problem with proto=50... So:
a) do UDP encap (maybe by manual config, if you are clueful)
b) call network support and file a problem report.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*