Subject: RE: TRIP and security

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 10:33:46 -0500

I don't think there is an overriding answer to this.
Megaco and Sigtran chose IPSEC, I'd like to keep going along
that path.  IPSEC is the major IETF security mechanism.  
TLS is there, and it's acceptable, but it's more of an ad-hoc solution
arising from Netscape's SSL.  
Not to demean it, I like the protocol in general, but given a 
choice, these days, I push IPSEC.  Note also that it's 
slightly better to choose IPSEC when you want to use IKE for 
Next Hop Authentication.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 11:08 AM
> To: Brian Rosen
> Cc: 'Matt Squire'; IPTEL IETF Mailing List
> Subject: Re: TRIP and security
> 
> 
> 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.
> 
> Brian Rosen wrote:
> > 
> > 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.
> 
> -- 
> 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
> 

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

---

From: Manjunath Bangalore <[email-masked]>
Date: Fri, 19 Nov 1999 17:49:22 -0800 (PST)

Hello, 

   I contacted this person John Bashinski, who is in Customer 
Advocacy/Support in the Security Organization for a while now
and have some of his thoughts enclosed below in response to the 
first discussion on this thread...

-Manjax

----
First, some comments on the specific stuff in his message:

> >   (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?

I think that you're almost certainly going to want to do this.

However, this is an area where you guys need to work out a model of what
sorts of policies you'll support, a threat model, and some idea of how
you want to be able to respond to things.

If you have the system that originally injected a route sign the
information, there must be a reason that you want to know who injected
that route. What do you do with the information? Are you going to use it
to make decisions about what routes to accept, or are you just going to
use it to figure out who to blame when something gets screwed up? How
does this work with aggregation?  Not very well, as far as I can see.

Is there going to be a policy as to who's going to be allowed to say
what about which gateways give you access to which phone numbers?
Without some sort of authorization policy, there's no point in
authenticating. Where is that policy information going to live, and how
is it going to be represented? Will authentication represent implicit
authorization for some things, and if so what things? Is there supposed
to be some kind of PKI?

Remember, if any TRIP speaker is allowed to claim that any IP address
is a gateway to any set of phone numbers, you're going to need a
very expressive policy mechanism to decide which such announcements
you really want to believe. Just proving who injected the route is
only the beginning.

You probably want to think about integrating the authorization for
injecting routes with the (non-TRIP) issue of how you decide who's
authorized to actually use a given gateway. You don't want gateways just
accepting calls from any random source that happens to manage to guess
its IP address. How does a gateway know who it's authorized to talk
to? Can you arrange it so that the same administrative action that
permits an entity to use a gateway also permits that gateway to be
advertised to that entity?

Administrative issues can really kill you. They've kept PKIs from being
adopted for SSL for years. Even if you have fabulous security support in
the protocol when it first comes out, you may or may not be able to
actually use it for quite a while.

> >   (2) Is Nested authentication a requirement, an option, or something to
> > forget about?

It depends on how important it is to know that the path is right, as
well as knowing where the actual route came from.

I'm not sure I understand what the path information is really used for
in the context of TRIP. It's obviously useful for avoiding readvertising
a route to somebody who already has it, but that could easily be
achieved by a simpler flooding-control mechanism. Since you're not really
routing traffic along the paths, it doesn't seem to have a routing
function. The only real use I can think of is policy support... so the
question is whether there are any policies that have to be securely
supported that require this information.

Personally, if I were designing the protocol, I'd ask myself some hard
questions about why I was maintaining this information in the first
place. If you have a use you care about, you probably have to
authenticate the path. Ask yourself what somebody could do to you... is
it just a matter of a minor loss of efficiency, or could they melt down
the whole infrastructure?

> >   (3) For Peer-to-peer authentication, is there a consensus toward IPSEC
> > or TLS as the preferred method?   

>From a purely Cisco-interested standpoint, IPSec is probably better,
since we already have IPSec code in routers. People implementing LSes on
general-purpose operating systems may prefer TLS, because the APIs are
more mature and because you can do TLS without modifying your
kernel. You can get more or less the protection you want out of either
one, so I don't see a huge security difference. IPSec does give you some
protection against things like SYN floods, but only at the cost of doing
a bunch of expensive signature checks, so I'm not sure how useful that
protection really is. IPSec is supposed to be The Future.

> >   (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)?  

Yes, you'd need your own IPSec SA for TRIP, almost certainly. The reason
is that the authorization model is probably going to require that you have
a separate PKI that defines who's allowed to make what claims in TRIP,
and that's going to mean using different keys for TRIP than for everything
else. Anyway, it's cleaner.

> > 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).  

You can ignore key management in the narrow sense. You can't ignore
policy management, you can't ignore the identity model, and you can't
ignore PKI semantics.

> > 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.

... and there's no operational experience with anything of the kind,
anywhere. All the same, I'd talk to the S-BGP people, and I'd do some
really hard thinking about how important it was to maintain that path
information. If you're relying on it, you need to authenticate it.
I'd look especially hard at whether aggregation will force you to
authenticate the whole path.

As far as performance goes, remember that a node doesn't always actually
have to use the signatures, even if they're there. If you need them, though,
it's pretty hard to use them if they're *not* there.

> > 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!].  

OK.

> > Finally, TRIP, as an infrasture controlling protocol, should use distinct
> > keys for its relationships and have its own IPSEC tunnel - just like I

OK.

A few random thoughts...

Work on the threat model. Make sure you understand what people may want
to do to you. Telephony is especially interesting because billing is
traditionally usage-sensitive. Might a carrier try to divert billable
traffic to itself? There's also a converse problem that doesn't happen
with BGP... might a carrier try to divert traffic *away* from itself
(presumably while still capturing the revenue) by advertising somebody
else's gateway?  That won't work in BGP (although there are bad things
you can do), because you can't advertise a route that doesn't go through
you. In TRIP, there's no such restriction.

Denial of service is obviously a huge concern. We sit around at
incident response meetings trying to figure out what happens when
the network is down and we can't even call anybody on the phone
to get it fixed.

Figure out exactly what the semantics of a TRIP advertisement are...  if
you get an advertisement with a path of (A, B, C) with C saying that
gateway X is a path to number range Y, it pretty clearly says that
gateway X is a path to Y... but what are the semantics of the rest?  I
think you can presume A is inviting you to use X. Does that mean that B
and C are also inviting you to use X, or at least have authorized A to
do so? Are *you* authorized to invite D to use X?

There are some implicit messages in an update, too: you need not
announce this route to A, B, or C, because they sent it to you... so
what are the implications if somebody forged the path deliberately to
keep you from announcing the route to them? You *do* need to announce
the route to D if you want D to have it...  what are the implications if
somebody deliberately removed D from the path to force you to
readvertise?

Work on models for who owns what, who's authorized to use what, and how
that information is represented and passed around. This is probably
going to mean doing a PKI with millions of weird X.509
extensions... either that, or doing an identity-only PKI and a set of
separate data structures to represent policy. It probably also means
identifying an organization or organizations to sign certs. I'd try to
integrate policy for all the protocols involved, not just TRIP. You'll
want to keep it policy-free, but what that's really going to mean is
policy-flexible; any reasonable model is likely to foreclose some class
of policies.

Aggregation is going to be a huge pain.

Watch out for simplistic DoS attacks. People do big, complicated crypto
protocols, and forget that anybody can then force them to do big,
complicated crypto operations to verify things. What's the impact if
somebody dumps a whole bunch of routes with bad signatures into the
mesh? The answer to this problem is careful implementation, with
fairness mechanisms to make sure that no one source can use up all of
your signature verification resources, and with care taken to keep from
forwarding obviously bogus data on to somebody else who'll have to
verify them again.

Watch out VERY carefully for attacks that slip in at the interstices
between the protocols. VOIP seems to involve an incredible number
of different devices, each of which uses two or three protocols, and
each of which has to communicate sensitive information to lots of
other devices. This is a great environment for unforseen interactions
to create security problems. Phreaking is coming back, big time.

---------