Re: [RPSEC] BGP Security Requirements v08

Curtis Villamizar <curtis@occnc.com> Thu, 19 July 2007 12:34 UTC

Return-path: <rpsec-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDV-00047K-Mw; Thu, 19 Jul 2007 08:34:49 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBVDU-00047B-52 for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:34:48 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDT-00046y-QK for rpsec@ietf.org; Thu, 19 Jul 2007 08:34:47 -0400
Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVDT-0006zU-4d for rpsec@ietf.org; Thu, 19 Jul 2007 08:34:47 -0400
Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6JCZZWv043998; Thu, 19 Jul 2007 08:35:35 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com)
Message-Id: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com>
To: Russ White <riw@cisco.com>
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
In-reply-to: Your message of "Wed, 18 Jul 2007 18:41:57 EDT." <469E9735.4080703@cisco.com>
Date: Thu, 19 Jul 2007 08:35:35 -0400
X-Spam-Score: 1.7 (+)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: rpsec@ietf.org, Sandy Murphy <sandy@tislabs.com>
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Errors-To: rpsec-bounces@ietf.org

In message <469E9735.4080703@cisco.com>
Russ White writes:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>  
> >>>> o The authentication information may be passed between authenticating
> >>>> implementations outside the BGP protocol.
> >>> Is this practical?  Pass information out of band to every far distant
> >>> BGP speaker rather than just to peers.
> >>>
> >>> This seems to break the "must be scalable" requirement for everything
> >>> related to routing.
> >>  
> >> Aren't the ROAs already being transmitted that way?
> > 
> > The ROAs do not provide authentication information to accompany a
> > packet or that pert of an AS path might be legitimate.  It just serves
> > to verify that a route could be originated at all by a given AS.
>  
> Whether a BGP packet is "authentic" is only a question hop by hop, and
> hence, anything transitive you carry within the packet doesn't help you
> much.
>  
> Whether an AS Path is valid is a long discussion, and we've had it many
> times before. Suffice it to say I believe it's possible in many ways
> without carrying anything in the BGP packet.

I do too but if it involves information using a slow, almost static,
OOB mechanism such as IRR or X.509 based ROA, then it needs some means
of expressing the possible AS adjacencies and the policies applied
over those adjacencies.  If so, we're right back to RPSL.  We might as
well just pick up that work and use a different underlying delivery if
the RPS work was considered unacceptable.

> > If you want to authenticate a routing packet you need a signature over
> > the packet or a digest.  Its fine to then provide the public keys OOB.
>  
> You're treating this like IPsec, where a packet originates at one end of
> a connection, and ends up on the other side of the Internet at the other
> end of that connection. Wrong. There's no way to know if a BGP "packet"
> is "valid," beyond a single hop. You can validate the information
> contained within the packet, but "validating" the packet across
> "multiple hops," is only one possible way to do it.
>  
> :-)
>  
> Russ


Sorry.  Should have said advertisement.

Curtis


> > For example, if the AS Path is A X Y Z and I trust my peer A but not X
> > and Y, the ROA only tells me that its OK for Z to have originated this
> > route and nothing about whether this could have legitimately passed
> > through Y and Z.  An authentication would be Z signature, Y signing
> > that, X signing that, and A passing along the signatures.  If 128
> > bytes are used per signature that is 384 bytes.
> > 
> > OTOH if some OOB mechanism also addressed whether a peering might be
> > legitimate, then requirements would be met.  So maybe its just that
> > the current ROA scheme (or schema) is inadequate.
> > 
> > Curtis
>  
> - --
> riw@cisco.com CCIE <>< Grace Alone
>  
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>  
> iD8DBQFGnpc1ER27sUhU9OQRAtgLAJwO7/Q/n6jjdFLDs/tA93HI74ZFywCgzJXU
> 12xxdMHHt2SAQRX2bAgCSLk=
> =7vX4
> -----END PGP SIGNATURE-----



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec