Subject: [IPsec] To UDP encapsulate or not

From: Herbert Xu <[email-masked]>
Date: Fri, 19 Dec 2008 08:56:25 +1100

Hi:

The current draft has added the statement:

	o Implementations MUST process received UDP-encapsulated ESP
	  packets even when no NAT was detected.

This has created implementation ambiguity which did not exist
before.  Back in IKEv1, NAT-T was a mess but we did have a way
to negotiate whether UDP encapsulation should be used on ESP
packets or not.

In IKEv2, this was done away with and it is implied that we should
decide on whether to use UDP encapsulation depending on whether
NAT is detected.

That is pretty vague but at least you could tell someone off for
performing UDP encapsulation without detecting NAT.

With the newly added statement, implementations now face a dilemma.
As it is now acceptable for the peer to send UDP encapsulated
packets in all cases, what should we do when sending data back?

If we choose to stick with unencapsulated ESP, then due to the
presence of firewalls (which unlike NAT devices cannot be easily
detected), this may never make it back to the peer.

So it would seem that the only safe option would in fact be to
send UDP encapsulated traffic.  But that's exactly what people
were trying to avoid due to the associated protocol overheads.

In other words, by adding that statement, we're in fact pushing
all implementors to use UDP encapsulation whether NAT is detected
or not.

Therefore I propose that the above statement be removed.

If a peer really wanted to use UDP encapsulation, it could easily
spoof the NAT detection payloads.  If you don't like that, then
we could also add explicit negotiation of UDP encapsulation just
as the original NAT-T scheme did.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email-masked]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 20 Dec 2008 17:15:22 +0200

Hi Herbert, 

I believe that this is a very useful statement given that there are many
NATs and firewalls out there and you never know whether you run into one. 

Having the server to implement UDP encapsulation and to be able to deal with
UDP encapsulated packets (regardless whether a NAT/firewall was previously
detected or not) is pretty useful. 

Are you worried about the increased packet size? 

Ciao
Hannes 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Herbert Xu
>Sent: 18 December, 2008 23:56
>To: [email-masked]
>Subject: [IPsec] To UDP encapsulate or not
>
>Hi:
>
>In IKEv2, this was done away with and it is implied that we 
>should decide on whether to use UDP encapsulation depending on 
>whether NAT is detected.
>
>That is pretty vague but at least you could tell someone off 
>for performing UDP encapsulation without detecting NAT.
>
>presence of firewalls (which unlike NAT devices cannot be 
>easily detected), this may never make it back to the peer.
>
>In other words, by adding that statement, we're in fact 
>pushing all implementors to use UDP encapsulation whether NAT 
>is detected or not.
>
>If a peer really wanted to use UDP encapsulation, it could 
>easily spoof the NAT detection payloads.  If you don't like 
>that, then we could also add explicit negotiation of UDP 
>encapsulation just as the original NAT-T scheme did.
>
>Cheers,
>--

---

From: Herbert Xu <[email-masked]>
Date: Sun, 21 Dec 2008 10:51:13 +1100

HI Hannes:

> Are you worried about the increased packet size? 

No I'm not so worried about the packet size myself (thoughs others
may).  I'm worried about the potential to create blackholes should
some implementations choose to use UDP encapsulation and others
choose not to.  Even if both sides are prepared to accept both
packets with and without encapsulation, the presence of stateful
firewalls in the middle can kill the connection if their choices
do not match.

So if we deem that UDP encapsulation's usefulness outweighs its
overheads, and we're not prepared to let it be negotiated, then
we should require it instead of leaving it up to the implementation
(in the case where NAT is not detected).

Cheers,

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 21 Dec 2008 19:09:55 +0200

Hi Herbert, 

I guess we agree on a couple of aspects, namely

* middleboxes can do all sorts of funny things and there is very little one
can do about it. 

In http://tools.ietf.org/html/draft-rosenberg-internet-waist-hourglass-00
Jonathan argues that the new waist of the Internet hourglass is based on
running everything over TCP and UDP. Some folks even claim that the new
waist is essentially HTTP/HTTPS. 
Hence, many applications today run over HTTP and some Ipsec implementations
even allow tunneling over HTTP in the worst case if everything else fails. 

* capability negotation is required to avoid using UDP encapsualtion whereas
the other side does not support it. 

* detection is difficult to accomplish (and at least expensive). 

In the original version of STUN folks tried to build-in a detection
functionality regarding the NAT type. This was later removed. While it is
possible to detect some types of NATs quite reliablely it is still costly to
perform the test exchanges -- more so in an mobile environment.

For firewalls the detection is more complex as the middlebox does not modify
the packet itself and hence the presence of dropped packet is the only
indication the two ends have. It could, however, be packet loss for all
sorts of reasons, including congestion. 

Ciao
Hannes

>> I believe that this is a very useful statement given that there are 
>> many NATs and firewalls out there and you never know whether 
>you run into one.
>> 
>> Having the server to implement UDP encapsulation and to be able to 
>> deal with UDP encapsulated packets (regardless whether a 
>NAT/firewall 
>> was previously detected or not) is pretty useful.
>> 
>No I'm not so worried about the packet size myself (thoughs 
>others may).  I'm worried about the potential to create 
>blackholes should some implementations choose to use UDP 
>encapsulation and others choose not to.  Even if both sides 
>are prepared to accept both packets with and without 
>encapsulation, the presence of stateful firewalls in the 
>middle can kill the connection if their choices do not match.
>
>So if we deem that UDP encapsulation's usefulness outweighs 
>its overheads, and we're not prepared to let it be negotiated, 
>then we should require it instead of leaving it up to the 
>implementation (in the case where NAT is not detected).
>
>Cheers,
>--

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Dec 2008 15:02:20 +0200

> to negotiate whether UDP encapsulation should be used on ESP

I did like the IKEv1 way to negotiate the UDP encapsulation
separately, but that was removed in the IKEv2.

> packets in all cases, what should we do when sending data back?

In normal case you never should not get any UDP-encapsulated packet
from the complient implementation of IKEv2 (without MOBIKE) unless
there is NAT detected.

With MOBIKE you MUST always be able to process UDP-encapsulated ESP
packets regardless whether there is NAT or not on the path (this is
required for the MOBIKE to work, as during transition from NATed
address to non-NATed address and back, you might get some packets UDP
encapsulated even when there is no longer NAT on the currently
selected path, or other way around. 

> detected), this may never make it back to the peer.

In MOBIKE you always make your own selection whether to enable UDP
encapsulation or not based on whether there is NAT between or not,
i.e. even when other end is sending you UDP encapsulated packets you
will send him back normal ESP if you do not see NAT there. With MOBIKE
after the address update signaling is done and other end also knows
there is no more NAT there, he should also drop the UDP encapsulation.

With base IKEv2 this situation should not really come up, as both ends
enable NAT-T based on the same rules, so both ends always enable it or
disable it. 

> were trying to avoid due to the associated protocol overheads.

That would offer new attack, where attacker can send one UDP
encapsulated packet (i.e. take ESP packet UDP encapsulte it, and send
it to other end) and it will cause the receiving end to switch to UDP
encapsulating packets too, which will then reach other end which will
cause it to start send UDP encapsulating packets too.

I.e the only workable solution is that you do not copy the
encapsulation selected by other end, but select it based on your local
policy. 

> Therefore I propose that the above statement be removed.

I think we can also drop it to SHOULD or MAY if needed, but I just do
not want to put it MUST NOT as that would create unnecessary
difference between IKEv2 with MOBIKE and without MOBIKE.

I.e. I at least want to have implementations who can always
decapsulate UDP encapsulated packets and process the IPsec packets
inside regardless whether there is NAT detected or MOBIKE support
enabled.

I also agree that creating black hole for return packets because they
do not use same encapsulation is bad, but I also do not think we can
copy the encapsulation as it offers too easy way to attack then. 

> as the original NAT-T scheme did.

That I agree also, i.e. if one end wants to enable UDP encapsulation
even without NATs present on the path, he can always spoof the NAT
detection payloads.

On the other hand the NAT-T in IKEv2 also has the problems with the
transport mode and the traffic selectors used there, and especially in
case both ends are behind NAT. We need to fix those things too... 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Herbert Xu <[email-masked]>
Date: Tue, 23 Dec 2008 09:35:06 +1100

> selected path, or other way around. 

Then I'm afraid that MOBIKE is doomed to fail (unless every MOBIKE
implementation always chooses to use UDP encapsulation) because
you can't get away from firewalls on today's Internet, especially
when you're mobile.
 
> difference between IKEv2 with MOBIKE and without MOBIKE.

I see your point of view.  But I'm loathe to see IKEv2 degenerate
into the same kind of interoperability blackhole that MOBIKE will
face just because MOBIKE requires it.  There's gotta be a better
way out of this.
 
> copy the encapsulation as it offers too easy way to attack then. 

Actually there is an easy way around this attack.  All we need
to do is only switch if

1) we've chosen to do unencapsulated ESP and we received a UDP-encapsulated
   packet, and

2) the incoming packet passes the ESP integrity check and replay checks.

This should guarantee that only the genuine peer can trigger this
change.

Cheers,

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Dec 2008 12:37:27 +0200

> you can't get away from firewalls on today's Internet, especially

I do not agree you on that, and I assume you do not agree me either as
my emails to you directly do get blacklisted by your mail server...
(while talking to rhun.apana.org.au.: >>> DATA <<< 451-sender IP
address 83.145.195.1 is locally blacklisted here. If you think <<< 451
this is wrong, please call...)

In MOBIKE this is mandatory as when we are switching addresses where
one address is behind NAT and another is not, there might be
situations during the transition, where the hosts do not agree which
address to use, thus other end uses address which do have NAT on the
path (and uses UDP encapsulation), and other end uses address pair
which do have NAT (and do not use UDP encapsulation).

Immediately when they again agree on using same addresses, and both
end know whether there is NAT or not, they switch to use same
encoding, i.e. UDP encapsulation if NAT was detected, and normal ESP
if no NAT was detected.

MOBIKE implementations will not use UDP encapsulation unless there is
NAT detected on the path they have selected (just like IKEv2). The
difference there is during address pair transition the peers might
have different address pairs in use. 

> face just because MOBIKE requires it.  There's gotta be a better

I do not really see how the ability to process INCOMING packets
regardless of the encoding generates interoperability blackhole. It
can convert two way blackhole to one way blackhole, but if there is
firewall between which blocks all ESP packets the (but does not NAT
them) that will cause connection to fail between the peers always. If
one end decides to use UDP encapsulation to get through firewall, that
will not still make the TCP or any other upper level protocol to work
over the link.

If one end wants to get past that kind of firewall, it needs to fake
the NAT on the path to get both ends using UDP encapsulation. 

> This should guarantee that only the genuine peer can trigger this

Attacker can still trigger that, as the ESP integrity check and replay
checks are not affected by the fact that the packet is UDP
encapsulated. I.e. attacker can take the normal ESP packet, wrap it up
to UDP encapsulation and send it to the destination, and it will pass
the ESP integrity check and if that packet comes in before the
original packet it will also pass the replay checks (or if we can
cause the original packet to be dropped).

I still don't really know what is your proposed solution?

In my proposal I do not change sending part at all, i.e. sending will
use exactly one encapsulation which is based on whether the NAT was
detected on the path or not. Only thing that is changed is that
implementations MAY/SHOULD/MUST accept incoming packets regardless
whether they have UDP encapsulation or not (i.e. if the packets
manageded to reach you and you are able to process them, then process
them and don't drop them just because they didn't have same
encapsulation which you are using when sending packets out).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Herbert Xu <[email-masked]>
Date: Tue, 23 Dec 2008 22:05:12 +1100

> cause the original packet to be dropped).

You're right the only way to do this sanely is to negotiate it
in IKE.

> I still don't really know what is your proposed solution?

My proposal is to get rid of this ambiguity where the other side
is allowed to use either UDP encapsulation or without.  We can
achieve this by choosing one of these two options:

1) Require either UDP or no UDP based on NAT.
2) Negotiate UDP encapsulation explicitly in IKE.

> encapsulation which you are using when sending packets out).

The problem occurs when a MOBIKE client sits behind a firewall
that

1) Allows all outbound connections;
2) Only allows inbound traffic that's part of an existing connection.

When that client tries to send out UDP encapsulated traffic and the
remote server replies with ESP traffic because there is no NAT, you
have a blackhole.

This is a pretty standard firewall configuration so the only thing
that's keeping MOBIKE working at all is NAT.  As soon as you remove
the NAT while keeping the firewall, the whole thing falls apart.

Cheers,

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 Dec 2008 14:48:31 +0200

Herbert Xu writes:
> is allowed to use either UDP encapsulation or without.

But the question was not about what other end is allowed to send, it
was what other end should be able to accept.

> We can achieve this by choosing one of these two options:
> 

The RFC4306 text says already following:

    1) If NAT is detected MUST enable UDP encapsulation (this also
       implictly means that MUST NOT send without UDP encapsulation if
       NAT was detected)

The ikev2bis added following:

    2) Even if NAT is not detected MUST be able to process received
       UDP-encapsulated ESP packets.

The text which is not in the either document is what you are asking,
i.e:

    3) Is sender allowed to enable UDP-encapsulation even if no NAT is
       detected.

The answers to 2 and 3 can be different, and from 3 we can also derive
one more question:

    4) If no NAT was detected does receiving UDP encapsulated packets
       cause any effect on the receiving side. 

Actually my original question number 5 to thread for issue #40 was
wrong, as it was really the question 3 here, not the case 2, so I
myself confused those things too...

I.e. we have to separate the sender and receiving side processing. For
the sender side we might want to be quite strict what is supposed to
be sent, and on the receiving side we might want to be more relaxed
what is accepted. This kind of specifications allows making extensions
in the future, which can still be backwards compatible with the
existing implementations and benefit from new features even with old
versions.

Lets try this once more (all of these next questions are only relevant
if NAT-T is supported, if NAT-T is not supported then neither end can
use port 4500 or UDP-encapsulation):

(Answers are either from RFC, ikev2bis draft or from me (the ones with
question mark)).

Q1) Using port 4500:

			INITIATOR/		RESPONDER/
			SENDER			RECIPIENT

Q1a) Can start		MAY? start (1)		MUST? accept
     from port 4500				incoming
     directly?					connections (2)
     (from #40)

Q1b) May/should/must	MAY/SHOULD NOT? do (3)	MUST? process 
     move to port 4500				requests (4)
     even when no NAT
     detected?

Q1c) May/should/must	MUST			MUST
     move to port 4500	(RFC4306)		(RFC4306)
     if NAT detected?

Q2) UDP encapsulation when not floated to port 4500 (i.e. still using
    port 500, and no NAT detected):

			INITIATOR/		RESPONDER/
			SENDER			RECIPIENT

Q2a) Can UDP		??? (5)			MAY/SHOULD? process
     encapsulation				incoming packets (6)
     be used?

Q3) UDP encapsulation when we have floated to port 4500 but no NAT
    detected (this assumes Q1b says we are allowed to do it):

			INITIATOR/		RESPONDER/
			SENDER			RECIPIENT

Q3a) Can UDP		SHOULD NOT? (7)		MAY/SHOULD/MUST? process
     encapsulation				incoming packets (8)
     be used?

Q3b) Should UDP		NO? (9)			see above
     encapsulation
     be always
     enabled if
     using port 4500?

Q4) UDP encapsulation when we have floated to port 4500 and NAT
    was detected:

			INITIATOR/		RESPONDER/
			SENDER			RECIPIENT

Q3a) UDP		MUST enable (10)	MUST process
     encapsulation				incoming packets (10)
     usage?

Q3b) Is non UDP		MUST NOT send (11)	MAY/SHOULD/MUST?
     encapsulated				process incoming
     packets allowed?				packets (12)

Notes:

(1) RFC4306 2.23 does not really say this but IKEv1 NAT-T (rfc3947)
    says this, see also (2)

(2) RFC4306 2.23 does say MUST listen on port 4500, and nothing
    forbids other end for starting from 4500, and if responder must
    listen 4500, and respond to request to there, I guess that means
    it is MUST.

(3) Almost same as (1), but different as in Q1a we do not know whether
    there is NAT or not, thus we do not really have option to move
    back to 500 when we notice there is no NAT. Here the question
    whether we are allowed to move to port 4500 even when no NAT was
    detected.  MOBIKE mandates this.

(4) See (3), and (2) but I would read "MUST listen" to so that
    responder must also process those packets. MOBIKE mandates this.

(5) I would say MUST NOT or SHOULD NOT, but nothing in documents say
    anything about this.

(6) I would be liberal and allow it here (i.e. at least MAY, but
    could also be SHOULD). Ikev2bis says MUST.

(7) If no NAT is detected there is no reason to use udp encapsulation,
    so we should discourage it. We could even say MUST NOT. Note that
    processing such packets is different question. MOBIKE allows this
    (i.e. if sender knows or suspects there is NAT it can enable it).

(8) Even if we say MUST NOT for the sender part, I think the recipient
    part should process those packets regardless of encapsulation.
    This does not mean we need to allow senders to send them now, or
    that we start sending them in same way we receive then. MOBIKE
    mandates this. Ikev2bis says MUST.

(9) I do not think the UDP encapsulation should be always enabled if
    using 4500, this is actually same question as Q3a, except than if
    we answer YES here then we cannot send non UDP encapsulated
    packets even if NAT was not detected but we moved to port 4500.

(10) RFC4306 says we MUST enable UDP encapsulation if NAT is detected.

(11) As we MUST enable UDP encapsulation if NAT was detected, that
     means we MUST NOT send non-udp encapsulation packets if NAT was
     detected.

(12) This is again different question than the sender side. This is
     close to the (6) or (8). I would say MAY/SHOULD/MUST process, but
     SHOULD/MUST NOT change its other behavior based on the fact it
     receives using wrong encapsulation (i.e. it SHOULD/MUST NOT
     enable his sending side based on what it receives). MOBIKE
     mandates this.

I think my previous summary is still valid:

Initiator can float to port 4500, regardless whether there is NAT or
not, and he can also do that from the beginning. If NAT-T is
supported, all devices MUST be able to receive both UDP encapsulated
and non-UDP encapsulated packets at any time, and process them both.
Encapsulation of incoming packets do not affect the encapsulation of
the sent packets, all devices decide sending format independly. If NAT
is detected all devices MUST enable sending UDP encapsulated packets.
As all devices must be able to receive and process both formats at any
time, the sender can change the encapsulation based on local
implementation matters (unless there is NAT detected, in which case
they MUST send packets UDP encapsulated).

(The first MUST could also be SHOULD or even MAY, especially for IPv6,
but on the other hand it might be that IPv6 IPsec implementations do
not support NAT-T at all so most likely if you run IKE over IPv6 you
do not enable NAT-T support).

> The problem occurs when a MOBIKE client sits behind a firewall that
> 

Complient MOBIKE client would never try to send out UDP encapsulated
packets, as there is no NAT there, unless it was before using some
other IP address pair which did have NAT. In that case it sends the
UDP encapsulated packets through the firewall, and those will get to
the other end. The client has already noticed here that the previously
used IP-address has disappeared or not working (thats why it moved to
use the other address which is behind firewall), and it starts address
update procedure. That will send IKE packet to the other end using the
firewalled connection. During this process it can still send ESP
packets out using previous NAT-T information but using new
IP-addresses, just to see if they go through (the other option would
be to drop them immediately when it notices the old address
disappeared).

When the server responds to the address update message, both end
notices there is no NAT and at that point both ends will disable UDP
encapsulation.

Client is also allowed to disable UDP encapsulation immediately when
it switches to the new IP-address pair if it "either suspects or
knows" that there is or is not NAT between them. I.e. it can for
example check if the source address of the new address pair is from
private address range, then it can immediately enable UDP
encapsulation, or it can see that it is globally routable address, so
it might disable the UDP encapsulation in that case.

Anyways the half black hole only exists as long as the address update
procedure is still running, after it is finished both ends agree
whether there is NAT or not between, and enable or disable UDP
encapsulation based on that.

As it might be bit hard to understand from the text above here is the
diagram for the packets when using MOBIKE. The IP_I1 is for example
WLAN link using NAT, and that is now in use.

	Client				Server
	------				------
	(IP_I1:4500 -> IP_R1:4500)
	UDP, ESP -->

			<-- (IP_R1:4500 -> IP_I1:4500) UDP, ESP

		Client is sending UDP encapsulated traffic to server
		using IP_I1 and server respondes to same address pair
		using UDP encapsulation.

		Now the WLAN link goes down and client detects this.
		It has another IP-address IP_I2 from fixed lan, and as
		now that is his only address, and IP_I1 does not work
		anymore, it decides immediately to move IPsec traffic
		to using that address, and start MOBIKE address
		update.

	(IP_I2:4500 -> IP_R1:4500)
	UDP, ESP -->

		As it does not know whether IP_I2 is behind NAT or
		not, it might guess it is behind NAT, or just keep the
		old NAT-T setting from the IP_I1 if it does not have
		any better way to make a guess (i.e. lets assume that
		neither IP_I1 and IP_I2 are private address space
		addresses). 

		It sends those packets out just in case they reach the
		other end, and then starts address update:

	(IP_I2:4500 -> IP_R1:4500)
	HDR, SK {N(UPDATE_SA_ADDRESS),
		 N(NAT_DETECTION_SOURCE_IP),
		 N(NAT_DETECTION_DESTINATION_IP)} -->

		Server replies to this:

			<-- (IP_R1:4500 -> IP_I2:4500)
			    HDR, SK {N(NAT_DETECTION_SOURCE_IP),
				     N(NAT_DETECTION_DESTINATION_IP)}

		After the update both ends know there is NO NAT
		between them, thus both ends disable NAT-T and send
		plain ESP packetS:

	(IP_I2 -> IP_R1) ESP -->

			<-- (IP_R1 -> IP_I2) ESP

> the NAT while keeping the firewall, the whole thing falls apart.

Yes, Standard IPsec (or MOBIKE) does not work through any firewall
which is configured to drop all ESP packets, and not do NAT.

Clients may have option which allows them to be configured to fake NAT
in such environments, to allow enabling UDP encapsulation even when
there is no NAT.

Even that does not help if firewall is configured to drop all port 500
and 4500 UDP traffic.

You can always misconfigure firewall to drop any traffic, but if you
want to get IPsec through a firewall you either need to:

     1) allow UDP ports 500, 4500, and ESP/AH packets.
     2) allow UDP ports 500, 4500 and do NAT.

The second configuration is very common for IPv4 firewalls. The first
configuration might come common for IPv6 firewalls.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Herbert Xu <[email-masked]>
Date: Tue, 30 Dec 2008 14:06:52 +1100

> (Answers are either from RFC, ikev2bis draft or from me (the ones with

Thanks for the summary!

No NAT

> Q3b) Should UDP		NO? (9)			see above

NAT
 
>      packets allowed?				packets (12)

These cases are the bone of contention.

In the absence of explicit negotiation of UDP encapsulation, my
preference would be MUST NOT to all of the above (5-9 and 11-12).

The reason is that we're making a document that impelmentors will
rely on to determine the behaviour of their software.  They often
don't have the time to fully investigate all the rationale of each
individual statement in the RFC.  Therefore we should strive to
avoid statements which have the potential of creating "compliant"
implementations that cannot communicate with each other.

As I have explained previously, the status quo would allow two
implementations that abide by the current draft documentation
but simply cannot communicate successfully when firewalls are
present.

> other IP address pair which did have NAT. In that case it sends the

FWIW the thread that led me here was in fact caused by a MOBIKE
implementation which sent UDP encapsulated packets when NAT was
not detected.

While such an implementation may be non-compliant as far MOBIKE
is concerned, it is unfortunately complaint with respect to IPsec
per the current draft document.
 
> encapsulation based on that.

Thanks for explaining the rationale for MOBIKE wanting to do this.

So essentially this mismatch of UDP encapsulation is allowed in
order to have the MOBIKE peers continue communication after an
address change and before both ends have agreed on the address
change.

I have to say that the current solution to this problem is rather
poor.  On the one hand, it now explicitly allows bogus IPsec
implementations which weren't explictly allowed before, and on
the other hand, it doesn't solve the MOBIKE problem that well.

The target audience of MOBIKE clients are much more likely than
the average IPsec peer to be sitting behind a firewall of the
kind that I described earlier.  As such the address update mechanism
as currently documented is going to cause a blackhole during the
address change anyway.

In other words, allowing UDP encapsulation mismatches have made
the IPsec specification worse while it's only making MOBIKE slightly
better.
 
> which is configured to drop all ESP packets, and not do NAT.

No I'm not talking about a firewall which drops all ESP packets,
I'm talking about a firewall which only allows inbound ESP packets
which are associated with an outbound ESP flow.  That is, it only
allows inbound ESP (src, dst) if it has seen outobund ESP packets
(dst, src).

Cheers,