Subject: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 2)

From: Russ White <[email-masked]>
Date: Mon, 29 Nov 2004 20:48:31 -0500 (Eastern Standard Time)

Below sig....

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

--

2.  Definition of Verifiable

    For the purposes of this document the word verifiable indicates the
    ability to determine through algorithmic means whether a unit of
    information is correct.

I do think we need something better here. Perhaps:

"Verifiable, within the context of a routing system, and as it's used
in this document, means the ability to validate the authorization of a
specific autonomous system to advertise a given prefix (or block of IP
addresses), and the ability to verify the immediate peer transmitting
the update has a route to the destination indicated in the update."

Or something like that (?).

3.  Incremental Deployments Requirements

Here is where we start getting into trouble. :-) We need to be able to
back up each of these requirements with some reasoning, or take them
out, I think. It might be better to spplit this out into two lists, a
list of things that operators would find unacceptable, and then a list
of things about BGP that shouldn't be changed, based on the first
list. Then you could refer back to the first list in the second list,
like this....

"By discussing BGP security proposals and solutions with various users
of the BGP protocol involved in large internetworks, including the
public Internet, equipment vendors, and others, we have determined the
following are important attributes of an interdomain routing system to
consider when designing a security system:

    o Convergence Speed

      Convergence speed is a major concern to many operators of large
      scale internetworking systems. Networks, and internetworks, are
      carrying ever increasing amounts of information that is time and
      delay sensative; increasing convergence times can adversely
      impact the usability of the network, and the ability of an
      internetwork to grow into new functions in the future.

    o Incremental Deployment

      We cannot count on any given security system for interdomain
      routing being deployed through a flag day, and we cannot expect
      operators to split a large internetwork into multiple pieces
      while a security system is being deployed.

    o Trust Level Variability

      Each secured environment might have different levels of
      requirements in terms of what is acceptable or unacceptable. For
      instance, in a military environment, it might not be acceptable
      to route to a destination until a full check of all information
      contained in an update is performed, while in many commercial
      environments, routing information might be checked
      periodically. Trust levels in different environments can also
      vary widely, and even between entities within the same
      environment.

These general requirements lead to the following specific requirements
for security systems designed for interdomain routing:

    o BGP's convergence speed SHOULD be equivalent with or without any
      security system implemented and deployed. Optimizations used to
      make BGP converge in acceptable times on existing hardware, such
      as update packing and peer groups, SHOULD NOT be impacted by any
      proposed security system.

      This supports the Convergence Speed requirement above.

    o Any developed and deployed security system MUST NOT disallow the
      forming of peering relationships between secure and nonsevure BGP
      speakers, and MUST be backward compatible in the formatting,
      transmission, and processing of routing information transmitted
      through a BGP peering session. The BGP peering FSM SHOULD be
      preserved.

      This supports the Incremental Deployment requirement above.

    o Any proposed security system SHOULD support the intermixing of
      secured and unsecured routes in a single BGP session between a
      single pair of BGP speakers. BGP implementations SHOULD be able
      to distinguish secured and unsecured routes without reference to
      items that can be stripped from a propagated routing update.

      This supports the Incremental Deployment requirement above.

    o The security system MUST support a range of possible outputs for
      local determination of the trust level for a specific route.  Any
      given route should be trustable to a locally configured degree,
      based on the completeness of security information for the update
      and other factors.

      This supports the Trust Level Variability requirement above.

    o The security system SHOULD allow the operator to determine
      whether the speed of convergence is more important than security
      operations, or security operations are more important than the
      speed of convergence.

      This facilitates the incremental deployment of security on
      systems not designed to support increased processing requirements
      imposed by the security system.

--

    Network recovery times for secured routing as well as unsecured
    routing SHOULD work with similar speed and SHOULD perform with
    equivalent, or greater, rapidity than legacy routing methods.
    Unsecured routing of secured prefixes MUST be supported so that a mix
    of secured and unsecured routing paths will provide security for the
    prefixes that have security features applied, but will not penalize
    or preempt "normal" prefixes.

I think I would take this section out, since it's pretty much covered
above, in the section on range of possible inputs requirement.

--

4.  Trust Models

4.1  Trust Model Examples

    One example of a trust model is a distributed trust system.
    Inter-domain routing as implemented today is based on the concept of
    distributed trust.  There is no central authority; each AS is free to
    choose whom to trust and whom to avoid placing trust in.  This model
    is expressed through the filtering of routing information received
    from BGP peers.  Financial contracts and business arrangements play a
    large role in how an AS chooses to filter their peers.

I think Steve is correct in stating the current Internet isn't really
a distributed trust model, per se. Internet routing is a distributed
trust model, perhaps, in the sense that you trust your neighbor to do
the right thing, who then trust their neighbor to do the right
thing--in effect, you're basing your trust for your neighbor on their
actions as well as on their their ability to monitor their trust
relationship with their neighbors.

    A second trust model is a hierarchical system much like how root
    certificates for SSL/TLS are distributed today.  In this model, a
    central authority controls all information.  For example, all address
    allocations are authenticated and signed by ICANN, then by a regional
    registry, then a large ISP, a small ISP, etc.  ICANN serves as the
    root of the address allocation system.  This type of trust is usually
    referred to as a strict hierarchical trust model or a chain of trust.

And here, I think we are trying to explain heirarchical trust model in
too few words, actually. I was poking around for some document we
could reference that actually defined the two trust models for us, and
found a few interesting leads, but nothing definitive.

I think the best thing to do here would be to reference a really good
explaination of the two models, something authorative, and then
provide a short example of each one in the same internetwork, to help
the reader understand the application to this problem, perhaps. I'm
hoping one of the security geeks in the WG can help us with a good
reference.

4.2  Trust Model Recommendation

    While there are a number of trust models available, a distributed
    ....

I think the thrust of this section is good, but there's not really a
lot of justification behind the requirements laid out. Perhaps
something like:

"In examining the various environments in which BGP is deployed, and
through discussions with various operators working within the context
of the public Internet, and other internetworks, it is apparent that
various types of trust models would fit specific environments better
than others. For instance, in the public Internet, a roughly
distributed trust model, following the current pattern of contractural
peering arrangements, would fit the business models of the
participants well.

In other environments, however, where a single entity can be said to
control the entire name space within the internetwork, a heirarchical
trust model would work better. Thus, any trust system specified in a
security mechanism designed for BGP must be flexible, and support both
a true distributed trust model among the participants in the
internetwork, and a fully heirarchical trust model among the
participants in the internetwork.

As heirarchical trust models are a subset (or a special case of) a
distributed trust model, any security system designed for BGP MUST
support a distributed trust model, and also MUST be able to support a
heirarchical trust model, if desired.

If two internetworks using different trust models are interconnected,
they MUST be able to interoprate, using locally determined levels of
trust to compensate for differences in their trust models where
necessary."

I don't know if this flows right, or has all the right words, but it
might be a step towards providing stronger justifications for the
requirement as presented.

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Blaine Christian <[email-masked]>
Date: Tue, 30 Nov 2004 17:19:13 -0500

> Russ

You are going to make us define authorization then...  Hmmm...  I stayed
away from authorization because of the slippery slope principle.  Authorize
works to a certain level but, in the end, it needs to be a network stability
choice.  Where does authorization end?  I think we do not want to see a
central "everybody goes here to make their network work" type model.  So, we
will need to define authorization at a "network" level vs. authorization at
an administrative level. Can authorization mean something like 3 out of 4
top tier ISPs agree that a certain ISP is authorized to propagate?

How about this for a rephrase: Verifiable, within the context of a routing
system, as detailed in this document, means the ability to validate the
originator of a specific prefix (or block of IP addresses) and the ability
to validate the session through which the prefix was received.

> consider when designing a security system:

I might reword a bit but your message is good...

>       through a BGP peering session. The BGP peering FSM SHOULD be

It probably works better if we just say "MUST allow" (I hate double
negatives).  I think the legacy peering FSM bits MUST be preferred.
Otherwise badness eh?  The case where it does not have to be preserved would
be a brand new "secured" connection.

>       items that can be stripped from a propagated routing update.

This was a bit painful to parse.  The way I read it though it sounds like we
are getting painted into a corner.  Does this mean a whole new "secured"
prefix propagation system is necessary?

>       imposed by the security system.

Since the paragraph will be rephrased in the bullets I agree.  However, I
think we need to come to terms with the secured propagation thing.  We put
the mix of secured/unsecured routing bit of that paragraph in there to cover
flag days etc...

Agreed and will change in the document.

> hoping one of the security geeks in the WG can help us with a good

I got two very nice emails on this from Radia and Tao (on the other thread).
I will forward to the group.

> requirement as presented.

I think it sounds great...  Much more detail...