Subject: Re: [RAM] Tunnelling Route Reduction Protocol

From: [email-masked] (Noel Chiappa)
Date: Wed, 22 Aug 2007 19:14:49 -0400 (EDT)

> From: "William Herrin" <[email-masked]>

    >> an obvious path to take in looking for delay improvments, which is
    >> to 'piggyback' the reverse mapping information on the connection
    >> opening.

    > There are several potential problems but the most serious is
    > authentication.

Yeah, I know - I've been doing some thinking in this area myself recently.
I know about the authentication - what are the other problems?

    > Theoretically a man-in-the-middle attack is possible, but
    > operationally it has proven to be a non-issue.

Well, there's also plain DoS - someone sends a packet claiming to be from
X, with a mapping for X, and the mapping is bogus, and sends the traffic to
somewhere random, or non-existent.

(Or by MITM did you mean that a bogus mapping would send the reply traffic
somewhere, which inspects it, and passes it on? I assumed you meant MITM in
procuring the binding, not MITM in the ensuing user data traffic stream.)

    > I can never trust data encoded in a random received packet to give me
    > valid route to a particular destination without first applying a
    > fairly elaborate authentication scheme.

Yes, that's the problem I'm struggling with ... :-(

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "William Herrin" <[email-masked]>
Date: Wed, 22 Aug 2007 19:52:19 -0400

> I know about the authentication - what are the other problems?

Hi Noel,

Well, if the ITR is expected to encode the return information in its
communication with the ETR then every possible ITR for a given source
address needs authoritative knowledge of every possible ETR for that
address and it has to be able to implement the policy rules for
traffic engineering with respect to those addresses. That requires
significant complexity in the ITRs and since the policy rules have to
match what the ITRs are capable of implementing, they're not likely to
be very flexible.

With strictly forward-lookups like what I have in TRRP, traffic
engineering is the responsibility of the route-server and it can be
arbitrarily complex.

> somewhere random, or non-existent.

I meant that man-in-the-middle is a theoretical issue with a DNS
lookup like proposed in TRRP. A MitM could forge the DNS reply,
causing the ITR to route traffic by way of an ETR on a network that
should never see it.

That's what DNSSEC is all about: it eliminates the attack vector.
DNSSEC hasn't been widely adopted because operationally the attack
vector hasn't proven to be a enough of a problem. If its not a problem
when mapping www.google.com to 1.2.3.4 then its not likely to be a
problem for mapping IP addresses to ETRs.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004