Subject: Re: [IPsec] To UDP encapsulate or not

From: Tero Kivinen <[email-masked]>
Date: Fri, 2 Jan 2009 13:48:14 +0200

Herbert Xu writes:
> 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.

If sender side is MUST NOT and server side is MAY/SHOULD/MUST be able
to process regardless of encoding, that still means that all complient
implementations can communicate with each other. It also means that
non-complient implementations (which violate the first MUST NOT) may
be able to communicate with the complient implementations (if they do
follow the MUST be able to process part).

That way does give us maximum interoperability.

Saying that recipient MUST NOT process incoming packets if they have
wrong encoding will NOT help interoperability.

Only thing that might confuse the implementor is that implementor
might read that "SHOULD/MUST be able to process" for the recipient
might indicates something about what the sender part can do, when it
does not say anything about that. If we have also separate MUST NOT
for the sender part, that should clear that confusion. 

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

Can you explain that case once more, with proper examples, as I have
not seen such case, where two implementations following the "MUST NOT"
for both sender and recipient would be able to communicate, but where
the two implementations where the sender follows MUST NOT and
recipient follows "MUST be able to process" cannot communicate.

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

As I explained complient MOBIKE can only do that during the transition
from one address pair to another, where the MOBIKE implementation
guessed incorrectly whether there is NAT or not between peers before
it has finished its NAT detection.

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

Nothing in the currnt draft says complient implementation would be
allowed to send UDP encapsulatated packets when NAT is not detected.
Can you point me to that text?

Current RFCs and drafts are silent about that, meaning it is unclear
whether it is allowed or not.

The ikev2bis draft adds text which says that if sender part follows
that unclear behavior then you still MUST process the received
packets, i.e. it tries to make it more interoperabile than before by
adding the "Implementations MUST process received UDP-encapsulated ESP
packets even when no NAT was detected.", but even it does not say
whether sender is allowed to send such packets or not. 

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

Yes.

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

Now you lost me again. Current solution is to be silent whether such
is allowed or not in both sender and recipient part. 

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

There is nothing we can do for that, we can only go around the NAT box
after we have been able to detect whether such exists or not. Before
that is done we cannot go around it... We could of course drop all
packets that come during the address change, but that would always
cause black hole when such address update is in progress.  Currently
we try to guess whether there is NAT or not between, and use
encapsulation based on that. If our guess was correct then packets
will continue flowing during transition. If our guess was wrong so
that we guessed there is NAT, but there wasn't, the packets still
continued flowing, but we wasted few bytes. If we guessed it
incorrectly that there was no NAT, but there was, then NAT dropped our
packets and we created that temporary black hole.

Note, that all this happens only if the original IP-address pair is
not usable anymore when we start the transition. If the old address
pair is still usable, we normally use that until we get the address
update process done.

> In other words, allowing UDP encapsulation mismatches have made
> the IPsec specification worse while it's only making MOBIKE slightly
> better.

I disagree on that.

> > > 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.
> > 
> > Yes, Standard IPsec (or MOBIKE) does not work through any firewall
> > 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).

Hmm... haven't really seen such firewalls, and such firewalls would
not be following the IPsec architecture, as the ESP flow is identified
by the SPI and dst-address. Source address might not be part of the
flow (for example for multicast traffic).

I have seen lots of NATs trying to do that, i.e. they see ESP packet
with SPI1, src, dst address going out and then they see incoming ESP
packet with SPI2, and then they associate those SPI1 and SPI2 same
flow, and try to do things on those. This does not work, and that was
the reason we did implemented the UDP encapsulation in the first
place. And as the NAT boxes broke things down by not doing the port
translation for IKE packets, we needed to move to port 4500 instead of
500, just to get around those broken NAT boxes.

I would myself consider such firewall broken and get proper firewall
instead. I think we should discourage firewall vendors for making such
assumptions which are not valid based on the IPsec architecture.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Herbert Xu <[email-masked]>
Date: Thu, 8 Jan 2009 19:48:41 +1100

> That way does give us maximum interoperability.

Sure, I can live with MUST NOT for the sender and MAY/SHOULD for
the receiver.  I don't think MUST makes any sense for the receiver
if we maintain MUST NOT on the sender.
 
> recipient follows "MUST be able to process" cannot communicate.

You've lost me, we currently don't have anything that says MUST
NOT for the sender.

> Can you point me to that text?

Last time I checked just because something isn't in the RFC doesn't
mean that it's forbidden.  Moreover, the current draft has added
a statement which implies that doing this will work by requiring
all receivers to accept them.

> is allowed or not in both sender and recipient part. 

Being silent means leaving things in the hands of the implementor.
As I said, the current draft may lead to implementations that are
unable to interoperate.

> that is done we cannot go around it... We could of course drop all

What you can do is continue to stick with the original decision.
That is, if you started out with encapsulation then continue to
use it, if you started out without encapsulation then continue
to that until the address change negotiation decides otherwise.

> > the IPsec specification worse while it's only making MOBIKE slightly

Great, I agree that we disagree :)

> flow (for example for multicast traffic).

This is a standard configuration on any stateful firewall which is
not IPsec-aware.  For instance, the Linux connection tracking system
treats ESP packets as generic IP packets and the only information
used to establish flows are the src/dst addresses.

Many commercial firewall devices operate in the same way.

> I have seen lots of NATs trying to do that, i.e. they see ESP packet

Note that I'm talking about firewalls, not NAT.  Everything I've
stated so far applies equally to IPv4 and IPv6.
 
> assumptions which are not valid based on the IPsec architecture.

The problem is not IPsec-aware firewalls, it's stateful firewalls
that know nothing about IPsec.  Making every firewall on the
Internet IPsec-aware is impossible.  That's why the NAT-T protocol
was invented in the first place.

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