Subject: [RRG] Security of TRRP mapping replies

From: Robin Whittle <[email-masked]>
Date: Mon, 25 Feb 2008 19:15:56 +1100

Hi Bill,

How would you secure each ITR from bogus map replies which pretend
to be from the authoritative nameserver?

It would be possible for an attacker to send a packet to host X,
with source address B.  The attacker wants the ITR which X uses to
cache some bogus mapping information.  The attacker reasonably
assumes the ITR will now issue a map request to a nameserver which
is authoritative for whatever /8 address B is in.  While the request
and genuine reply is in transit, the attacker sends a bogus packet,
using the nameserver's address as the source.  The ITR sees this as
the authentic mapping information and caches the result.  That
mapping results in all packets for address B (and others in the same
micronet?) being tunnelled to the attackers ITR.

This affects packets from any host which relies on the ITR.  So the
real victim may be on nearby host Y, when they send packets to B.

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "William Herrin" <[email-masked]>
Date: Mon, 25 Feb 2008 18:01:18 -0500

>  to be from the authoritative nameserver?

Hi Robin,

TRRP relies on mostly on security mechanisms present in DNS itself.
The request includes a serial number. The same serial number has to be
in the reply. Unsolicited replies and replies containing information
outside their scope of authority are ignored.

This is generally effective. Google has not suffered much in the way
of DNS hijacking above the worm-changes-client-dns-resolver level.
Neither has anyone else. The attacks you've heard of, such as cache
poisoning, trace to bugs where the above two requirements were
misimplemented.

DNSSEC is compatible with TRRP as far as I can tell, but it's not
required. DNSSEC has not been widely adopted because the
operations-level need has not demonstrated itself.

I bet the question you want to ask is: how would TRRP have handled
this weekend's YouTube hijacking?

That's hard to say with certainty since BGP doesn't completely go away
with TRRP. A bad actor with access to the DFZ's BGP system can do
significant if temporary damage and TRRP doesn't fundamentally change
that. Presumably AS 17557 is large enough that they'll still be
talking BGP with at least one short PA prefix at their border.

On the TRRP/DNS side of things, they could trivially effect an
intercept and rewrite of the DNS lookup requests for YouTube's ETR
from within Pakistan. On the other hand, getting that to leak without
fouling something up on the BGP side would be as close to impossible
as any such things tend to get.

TRRP doesn't draw traffic with a knowledge push so there's no path for
the intercept knowledge to flow through.

Regards,
Bill Herrin

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

---

From: Robin Whittle <[email-masked]>
Date: Tue, 26 Feb 2008 10:32:43 +1100

Hi Bill,

You wrote:

> TRRP relies on mostly on security mechanisms present in DNS
> itself. The request includes a serial number. The same serial
> number has to be in the reply. Unsolicited replies and replies
> containing information outside their scope of authority are
> ignored.

OK - sorry I was so ignorant about DNS basics.

> A bad actor with access to the DFZ's BGP system can do 
> significant if temporary damage and TRRP doesn't fundamentally
> change that.

Any map-encap scheme introduces extra complexity, and so provides
more opportunities for things to go wrong by accident, or by
intentional actions.  When the proposals are developed with more
detail it will be possible to discuss any potential vulnerabilities
they open.

BTW, a technical account of the YouTube Pakistan Telecom event is:

http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

  Regards

    - Robin