Subject: [mobile-ip] About triangular routing

From: [email-masked]
Date: Fri, 7 Feb 2003 13:36:39 +0530

Hello
I have a question about triangular routing
In Appendix B Section "B.2 Triangular routing " it is mention that Due to
the concerns about opening reflection attacks with the Home Address
destination option, this specification requires that this option must be
verified against the Binding Cache, i.e., there must be a Binding Cache
entry for the Home Address and Care-of Address.

And in section "9.3.1 Receiving Packets with Home Address Option" it is
mentioned that tests of Home address option must not be done for the packet
with home address option and BU or for IPSec AH or ESP packets
This is little confusion.
I think for the packet with Home Address option and IPSec AH or ESP CN
should not verify the option against binding cache entry for the Home
Address and Care of address

is it correct?

Regards,
Arvind

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Feb 2003 14:38:09 +0200

> Address and Care of address

We removed triangular routing per earlier discussion (#53). Later,
(#216) we observed that ESP could hide the fact that a BU is being
carried so its hard to make the determination at the stage when the ESP
packet is being processed. The proposal at one time was to remember
that the HAO check needs to be done until IPsec decryption was
complete. However, in terms of processing it was seen easier to
handle each step with the information that is available. So: the
final text was that BUs, ESP, and AH are exempt from the rule
on the receivers. Still, the spec disallows sending ESP or AH
packets with a HAO unless (a) BCE exists or (b) its a BU. So
from the sender side we have no problem.

I guess the question is if just allowing this on the receiver
side is problematic. Looking back at issue #53, I'm starting
to wonder if we forgot some of the lessons when discussing
the later issue. Basically, the question is what kind of
IPsec SAs qualify as trusted enough to avoid reflection attacks.
Even if our correct senders never send these things, the
malicious nodes could exploit our requirement to accept
these packets.

On the other hand, I like the new text because it performs
all checks locally without requiring a lot of co-operation
between stack parts.

Perhaps one way to resolve this would be to allow the ESP/AH
check only for addresses for which the node in question is
acting as a home agent. This guarantees the existence of
SPD entries of suitable form. So, maybe instead of "These
tests MUST NOT be done for packets that contain a Home
Address option and a Binding Update, or for IPsec AH or
ESP packets." we could say

   "These tests MUST NOT be done for packets that contain
    a Home Address option and a Binding Update. They also
    MUST NOT be done for IPsec AH or ESP packets with a
    Home Address option containing an address for which
    the receiving node could act as a home agent."

Jari

---

From: Brian Haley <[email-masked]>
Date: Fri, 07 Feb 2003 15:11:12 -0500

>     the receiving node could act as a home agent."

This text is in Section 9.3.1, which is the CN packet processing
section, so I wouldn't think the HA comment would even apply.
And won't this now stop IPsec from working between a MN and
CN, even though the draft doesn't specifically allow it?

I might have mis-understood this...

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Feb 2003 23:06:44 +0200

> section, so I wouldn't think the HA comment would even apply.

Hmmm... you may be right. But since ancient times, it seems
that a lot of the CN functionality has been assumed to be a
part of the HA functionality as well. I don't think we explicitly
say this anywhere in the draft though. Maybe 10.3.1 should explicitly
say how the home address option is to be verified.

> CN, even though the draft doesn't specifically allow it?

Not as far as I can understand. The rule is about when to
check for existence of the BCE, not about when to allow IPsec.
All this means is that you don't suddenly start to allow HAO
just because someone turned on IPsec. But IPsec when you have
route optimization on, or IPsec when you are using bidirectional
routing works just fine.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Feb 2003 16:26:05 +0200

Brian et al,

Here's some proposed text. This text keeps the correspondent node
case simple, and explicitly describes that the home agent
must do the HAO validation in a particular way:

Section 9.3.1:

   "... These tests MUST NOT be done for packets that contain a Home
    Address option and a Binding Update. "

Section 10.3.1:

   "A Home Address destination option MUST be present in the
    message. It MUST be validated as described in Section 9.3.1 with
    the following additional rule. The Binding Cache entry existence
    test MUST NOT be done for IPsec packets when the Home Address
    option contains an address for which the receiving node could act
    as a home agent."

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Feb 2003 16:31:35 +0100

Section 9.3.1:

   Section 10.3.1:

=> I am not satisfied at all with this because the IPsec validation
should be more than enough. Of course an IPsec header does not always
validate the HAO, there are some conditions, but they are always
fulfilled in the case of a home registration.
So PLEASE give us back the triangular routing with IPsec!

Regards

[email-masked]

PS: the conditions are very simple and can be summarized in:
the IPsec processing must be able to authenticate the home address.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Feb 2003 19:12:16 +0200

> the IPsec processing must be able to authenticate the home address.

Perhaps, but I think we discussed this in the past and the wg
concluded not to include that functionality. In the summer,
remember? With the big discussion that involved the MUST requirements
for all IPv6 nodes, the various ways for which IPsec SAs were
established etc. Do we need to reopen that discussion?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Feb 2003 12:15:16 +0100

=> if you don't want strong objections at the IETF last call,
we have to solve this problem.

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 14 Feb 2003 01:30:34 +0100

> established etc. Do we need to reopen that discussion?

That was issue 53, closed by leaving triangular routing to be specified
in a separate document.

> we have to solve this problem.

Last call was over on february 6, Arvind started this thread on feb 7th.

After discussing with Raj and Jari, in light of the above we move to
reject this renewed call to specify triangle routing in the base
spec. This was the previous decision and we see nothing that
indicates that suddenly the protocol is broken without it.
It continues to be an optimization which is non-essential and
can be specified separately.

-gabriel