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

["Panwei (William)" <[e-mail]>]

Michael Richardson <[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.

    > 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 <[e-mail]>, Sandelman Software
    > Works
    >  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
    > 
    >