Subject: RE: TRIP and security

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Nov 1999 09:05:06 -0500

I'm of the same opinion:
	IPSEC
	Next Hop Authentication

I'd give up Next Hop if we start getting wound up in protocol
and/or security hole arguments - it's nice, but not vital.
If we can quickly come to agreement on the language, and 
the security experts bless it (and whatever caveats we
have to apply), then I'd be in favor of having it.

Brian
------------
Brian Rosen, Principal Engineer
FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked] 

> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 6:34 PM
> To: IPTEL IETF Mailing List
> Subject: TRIP and security
> 
> 
> 
> 
> 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.
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Nov 1999 11:07:30 -0500

Brian,

I'm curious, is there a reason for IPSEC above TLS? I'm not enough of a
security
expert to know when to use one over the other.

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. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Nov 1999 08:18:25 -0800 (PST)

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

---------