Subject: TRIP and security

From: "Matt Squire" <[email-masked]>
Date: Tue, 16 Nov 1999 18:34:00 -0500

At the WG meeting in DC, we talked about some of the possibilities for
security measures in TRIP.  We're hoping to get input on what the group
feels are the security requirements.  

We mentioned 3 possible levels of security that could be included in TRIP:

(a) Peer-to-peer Authentication.  Basically, use existing security
protocols (IPSEC or TLS) to secure the TCP connection between adjacent LSs.
 This would provide assurance that the data is received exactly as it is
transmitted by the peer.   

(b) Next-Hop Authentication.  The idea here would be to include a signature
over a subset of the information that is associated with the next-hop
server, and that this signature be carried with the advertisement as long
as the next-hop server hasn't changed.  For example, in the following
scenario, suppose A advertises a route to B, and B advertises it to C
without changing the next-hop:
 
                       -------
                       |  B  |
                       -------
                     /         \
                    /           \
                  -----       -----
                  | A |       | C |
                  -----       -----
    Advertises:                    Wants to Authenticate next-hop, MED, Cost!
      Destinations: +1-202*
      Next-Hop: A1 in domain A
      MED = 5
      Cost = $.05/min
      Signature: by A

When C receives the advertisement, it could verify that the attributes
associated with the next-hop (next-hop, MED, cost, etc) have not been
altered by an intermediate LS (ie B couldn't have changed the information).
 This potential security mechanism can provide authentication for
attributes that are associated with the next-hop or signalling path (ie
that shouldn't be changed unless you are inserting yourself into the
signalling path).  

(c) Nested Authentication.  There are a few drafts working on adding what
we called Nested Authentication to BGP.  Basically, when a BGP speaker gets
the path attribute, it adds itself to the path, signs it, and passes it on.
 This allows a receiver to authenticate the entire path (ie at each member
on the path), to verify that each speaker actually signed it, and actually
advertised it to the next speaker in the path.  This approach is further
discussed in:
  draft-murphy-bgp-secr-03.txt
  draft-clynn-s-bgp-protocol-00.txt
As mentioned in these drafts, nested authentication is complex, expensive,
and is unclear in the presence of aggregation. 

Note that both next-hop and nested authentication are used to prevent
'insider' attacks, ie if an authorized LS gets corrupted or malfunctions.
These offer some limited protection against the type of damage a corrupted
system can cause, and they offer information to help track to the corrupted
system.   Peer-to-peer authentication is enough to guard against outsider
attacks.  

Some of the issues on which we need input are:
  (1) Is Next-hop security a requirement, an option, or something we should
just forget about.  Ie, should we support mechanisms for signing an
attribute set such that this attribute set and signature can travel
multiple hops?
  (2) Is Nested authentication a requirement, an option, or something to
forget about?
  (3) For Peer-to-peer authentication, is there a consensus toward IPSEC or
TLS as the preferred method?   
  (4) Should we use 'special' keys for the TRIP protocol, or the standard
keying mechanism for the domains (ie should TRIP require its own IPSEC
tunnel)?  

To get the ball rolling, I'll throw in my 2 cents.  

I kinda like the idea of the next-hop security, especially for the MED and
cost attribute (if we have a cost attribute).  It doesn't seem that
difficult *if* we can ignore key management issues (just point to IKE or
the like).  

The nested authentication scares me and its benefits don't seem that great,
so I'd prefer not to do it.  Even after reading the drafts, some of the
finer points still seem fuzzy and it seems like it would take forever to
authenticate.

Although TLS would probably be easier to specify and code, I lean toward
IPSEC as the tool for peer-to-peer security [I do NOT claim to be a
security expert!].  

Finally, TRIP, as an infrasture controlling protocol, should use distinct
keys for its relationships and have its own IPSEC tunnel - just like I
think all important control protocols should have.  

Comments?

- Matt

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 18 Nov 1999 11:39:52 -0500

At 08:18 AM 11/18/99 -0800, [email-masked] wrote:
>Let me ask a more naive question here. Do we expect all networks to have a
>direct relationship, or is it possible for a provider to get service through
>another provider, such as a broker? If the latter is possible, do we need to
>protect against the intermediate provider (node) from modifying data (such as
>cost) in the messages?
>
>(I hope that I formulated my question properly).
>
>PatC

The broker possibility is one of the potential justifications for the
next-hop security proposal.  I don't recall the group really coming to a
consensus on whether support of such brokering is a requirement.  But
coming at it from the other side, next-hop authentication doesn't *appear*
too difficult, supports this proxy scenario, so why not do it.  

I might quickly change my mind if the can of worms suddenly gets ugly.  

>> 
>> I agree with Matt that next-hop is probably a good thing, but that
>> nested
>> authentication is too complex, and kind of scary. Also, it assumes (I
>> imagine)
>> that I have the keys for every hop along the way, to verify each nested
>> signature.
>> Seems unlikely without a PKI. 
>> 

Note that next-hop authentication also assumes some PKI because you don't
have a direct association with everyone that may receive attributes that
you authenticated - you don't necessarily know where your stuff will end up.  

- Matt

---------