Subject: Re: [karp] Gap Analysis and Requirements

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 1 Mar 2010 17:56:46 -0800

Manav,
I prepared the draft-ietf-karp-threats-reqs-00 document today and published
it. I quickly went through your list below and checked that the items were
included. I made modifications where your points were absent. I've tried to
list which requirements in the document's section 3 address your points
below, by requirement number in section 3.

If you find there are gaps, pls point them out and we can address them in a
subsequent release this week.

see inline below...

On Sat, Jan 30, 2010 at 4:32 AM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Folks,
>
> Some thoughts for the text for the design guidelines document on the things
> that the authentication mechanism for routing protocols must bear in mind.
> Can this be used for the gap analysis? Its not yet complete and am bouncing
> this off you guys just to make sure that I am not too much off the course.
>
> --
>
> In this section, we present the requirements for a future routing protocol
> authentication and security mechanism, based on the consensus of the KARP
> design team. These requirements are intended to be used as a means of
> designing potential solutions within the individual routing protocol working
> groups.
>
> (1)     The routing protocol authentication mechanism must be able to
> accommodate rekeying. This is essential since its well known that keys must
> periodically be changed.
>

3.8 & .9

>
> (2)     A rekeying event must not affect the functioning of the routing
> protocol. In case of OSPF rekeying requires coordination among the adjacent
> routers.
>

3.8, .9

>
> (3)     The security and authentication mechanism must support both manual
> configuration of preshared keys and automated key management. This allows
> for different kinds of operation depending on the users particular
> deployment environment.
>

3.12, .13

>
> (4)     Routing protocol authentication mechanism must be oblivious of how
> the keying material was obtained. This decouples the authentication
> mechanism from the key management system used.
>

 3.14

> (5)     Routing protocols provide prioritized treatment to certain protocol
> packets (eg OSPF HELLOs and ACKs against other OSPF packets) and the
> authentication mechanisms should be able to work around this.
>

3.15

>
> (6)     In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all speakers
> share the same key on a broadcast segment. Possession of the key itself is
> used for identity validation and no other identity check is used. This opens
> a window for an attack where the sender can masquerade as some other
> neighbor. Routing protocols should thus use some other information besides
> the key to validate a neighbor.
>

not included yet. I think part of this belongs in the threats section. I
think another part may belong in the requirements section, but it's not
clear to me yet. Let's discuss it more.

>
> (7)     Routing protocols that rely on the IP header (or information beyond
> the routing protocol payload) to identify the neighbor which originated the
> packet must either protect the IP header or provide some other means to
> identify the neighbor.
>

not included. I think you are saying here that the mechanisms should be able
to support NAT, correct? If so, I think we need to have a dicussion on this
first.

>
> (8)     Routing protocols generally do not require confidentiality however
> the authentication mechanisms should not preclude the possibility of
> providing that support.
>

It's a good idea, but I'm not sure how realistic this is. I'll put it in,
but not sure it will remain. 3.18

>
> (9)     Routing protocols authentication mechanisms must provide support
> against replay attacks. Should there also be a provision within the routing
> protocols to indicate that the replay protection is not being used?
>

3.5 & 3.6

>
> (10)    Replay mechanisms provided by the routing protocols should work
> even if certain protocol packets are offered prioritized treatment.
>

3.6

>
> (11)    Routing protocols that run at millisecond intervals (eg BFD) must
> either provide for a larger sequence number space so that it does not wrap
> around fast or some mechanism must be defined which works with smaller
> sequence number space.
>

3.19

>
> (12)    Routing protocols must specify at least one cryptographic algorithm
> or construction whose use it supported by all implementations and can be
> safely assumed to be supported by all implementations.
>

3.3

>
> (13)    Routing protocol authentication mechanisms must use cryptographic
> algorithms and constructs that are accepted by the IETF community.
>

3.2

>
> (14)    The authentication mechanism must be capable of supporting
> algorithms other than its defaults, in order to adapt to future discoveries.
>  An implementation that supports multiple algorithms must permit different
> neighbors to use different algorithms.
>

text added to 3.3.

>
> (15)    Routing protocols must only send minimal information regarding the
> authentication mechanisms and the parameters in its protocol packets to
> avoid exposing the information to parties on the path.
>

Not included at this time. This may a design guide or a security
consideration. As worded, it's very difficult to determine as a requirement
if it was fulfilled or not. See?

>
> (16)    Routing protocol authentication mechanisms should provide neighbors
> a way to ignore the authentication information arriving in the protocol
> packets.
>

Is this something that must be specified in the auth mechanism itself? Not
included at this time, as I'm not sure how to word it so that it can be
objectively measured as to whether it was achieved or not.

As we work these out we can update into a -01 pretty quickly, as in before
the next cut-off next week.

Gregory.

> --
>
> Cheers, Manav
>
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
>
>
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 2 Mar 2010 07:50:01 +0530

Gregory,
 
>> (7)     Routing protocols that rely on the IP header (or information beyond the routing protocol 
>>  payload) to identify the neighbor which originated the packet must either protect 
>> the IP header or provide some other means to identify the neighbor.

> not included. I think you are saying here that the mechanisms should be 
> able to support NAT, correct? If so, I think we need to have a 
> dicussion on this first. 

No, I was not alluding to NAT.

You can look at section 6.1 (for RIP) and section 2.2 (for OSPF) from draft-ietf-opsec-routing-protocols-crypto-issues-03.txt to see how somebody could launch an attack on these protocols by modifying information in the IP header.

>> (8)     Routing protocols generally do not require confidentiality 
>> however the authentication mechanisms should not preclude the possibility 
>> of providing that support.

> It's a good idea, but I'm not sure how realistic this is. I'll 
> put it in, but not sure it will remain. 3.18

Yup, even I don't think we would want confidentiality with routing protocols, however, we should not design a framework that precludes us from using one, if required in the future.

>> (10)    Replay mechanisms provided by the routing protocols should work even if 
>> certain protocol packets are offered prioritized treatment.

Ok, I had missed this one.	 

Cheers, Manav