Subject: [Roll] [roll] #118: draft-ietf-roll-security-threats-01.txt --- Verify relation with RFC 1636/4949 - Considerations on ROLL Security

From: "roll issue tracker" <[email-masked]>
Date: Wed, 08 May 2013 17:48:55 -0000

#118: draft-ietf-roll-security-threats-01.txt --- Verify relation with RFC
1636/4949 - Considerations on ROLL Security

 Comments done by Sean Turner (ST), source:
 [https://datatracker.ietf.org/doc/draft-ietf-roll-security-
 threats/ballot/]

 s3: After reading the first paragraph in s3 and comparing it to the output
 of the IAB workshop (RFC1636) I'm left wondering if it's doing the same
 thing.  RFC 1636 says:
   Securing the routing protocols seems to be a straightforward
 engineering task.  The workshop concluded the following.
    a)   All routing information exchanges should be  authenticated between
 neighboring routers.
    b)   The sources of all route information should be  authenticated.
    c)   Although authenticating the authority of an injector of route
 information is feasible, authentication of operations on that routing
 information (e.g., aggregation) requires further consideration.

 S3 closes with:

   In the case of routing security the focus is directed  towards the
 elements associated with the establishment and maintenance of network
 connectivity.
 The word focus kind of threw me and later in s3.4 you list the fundamental
 functions of a routing protocol.  Is the threats or the things you're
 trying to secure.  And, as Steve pointed out in the secdir review most
 think of routing security is ensuring the proper functioning of the
 routing protocol.  And, you say you're using definitions from RFC 4949 but
 the one for "security".

 Later in the paragraph you have "authentication, and potentially
 integrity, and confidentiality" kind of hangs there after authorization.
 Authentication, integrity, and confidentiality of what?  Also if you're
 going to do authentication I  guess you might not need integrity, but I'd
 sure like to know how that happens.

 Maybe some tweaks could solve all this:
 Routing security, in essence, is about ensuring the routing protocol
 operates correctly [insert reference if there is one].  It entails
 measures to ensure ...

 and then (injectors was the IAB's word and maybe we can come up with a
 better one - or we define a new term in the definitions section)

 State changes would thereby involve not only authorization of injector's
 actions, authentication of injectors, authentication, integrity, and
 potentially confidentiality of routing data, but also proper order of
 state changes through  timeliness, since seriously delayed state changes,
 such as commands or updates of routing tables, may negatively impact
 system operation.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  security-threats         |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/118>
roll <http://tools.ietf.org/wg/roll/>