Subject: [karp] Comments on draft-ietf-karp-design-guide

From: Sam Hartman <[email-masked]>
Date: Thu, 13 May 2010 14:52:25 -0400

Hi.  I ended up re-reading the design guide because I got some
questions from some folks in the working group I'm working with.
Their questions indicated that they were thinking about this problem
differently and I wanted to try and find an explanation of where we
are with this.

I have one huge comment that came out of this review and the questions I raised.
It's entirely unclear in our documents what functions belong to the KMP  and what functions belong to the routing protocol.

For example, if my routing protocol has a long-term key, and exchanges
nonces and then generates a traffic key from the long-term key and the
nonces, it is performing key-management functions.

We need to be much more clear about where the boundary is with our key
management protocols.
I think the place to do this is problem the design guide.

  I suspect many of these remaining comments may already have been made in
the past.

Section 2:

It's not clear to me that RSVP really fits into the category of a
one-to-one routing protocol.  I thought RSVP path messages were intended
to be consumed by all RSVP speakers along a path.  So, RSVP may have
very unique security properties because you may not even know before
sending a message who will consume it.

Section 3.2: With modern cryptographic primitives I don't think we're
seriously concerned in most cases about an attacker building up a set of
ciphertexts.  There are a few exceptions: counter reuse for GCM springs
to mind, but for the most part, the argument in section 3.2 does not
hold water.

I think the reason for rotating keys that remains is concerns about
access to keying material over time, especially as who has access
changes.

>In this future environment, we do
>      not anticipate an environment where the automated key management
>            protocol will be used to create short-lived cryptographic session keys
>	          for the security of routing protocols.

Why don't we anticipate that?
If this statement is going to remain it needs a lot more justification behind it.
Section 4:

>      world.  For example, a provider's edge router at a public exchange
>            peering point will want to use a KMP for ensuring unique and fresh keys
>	          with external peers, while a manual key may be used between a
>		        provider's access edge router and each of the same provider's customer
>			      premise routers with which it peers.

I'd recommend striking this example because I don't think it
represents particularly good security policy.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 15:12:35 -0400

I will leave the rest of the quesitons for others, but I want to comment 
on one of Sam's quesiton.

We are not doing RSVP.  We are doing RSVP-TE.
Even so, one could look at that as a message originated by the head end, 
and passed down to the tail   Or, one can look at it as a message passed 
by a router to its neighbor, with enough information that the neighbor 
can create a suitable message to pass on to its neighbor.
Given the defined scope of the working group, the protection we are 
interested in is the protection between a router and its neighbor.
It may well be that there are sufficient mechanisms already in place in 
RSVP-TE.  But until we check, we don't know.

Yours,
Joel

Sam Hartman wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 13 May 2010 15:37:17 -0400 (Eastern Daylight Time)

(Repost to get From address to match subscription, hopefully without 
generating duplicates.)

RSVP attempts to communicate information from end to end, but each hop 
might modify that information in certain defined ways.  RSVP-TE shares 
this behavior e.g., from RFc5151:

    The ERO that a domain border node receives in the Path message was
    supplied by the ingress node of the TE LSP and may have been updated
    by other nodes (for example, other domain border nodes) as the Path
    message was propagated.

This same behavior pattern appears in BGP, for example.

That makes end-to-end protection of authenticity and integrity a much more 
complex problem.

The hop-by-hop protections between RSVP speakers is a more approachable 
problem.

So characterizing RSVP as a one-to-one protocol might be more appropriate 
for the purpose of determining cryptographic requirements and design goals 
if you don't intend to take on the larger problem of end-to-end protection 
of information that is changed en-route.

I don't have a good term to use to describe the protocols that work like 
this - "bucket brigade"? "distributed incremental computation"? "rolling 
stone gathering moss"? ugh.

--Sandy

On Thu, 13 May 2010, Joel M. Halpern wrote:

> I will leave the rest of the quesitons for others, but I want to comment on 
> one of Sam's quesiton.
>
> Even so, one could look at that as a message originated by the head end, and 
> passed down to the tail   Or, one can look at it as a message passed by a 
> router to its neighbor, with enough information that the neighbor can create 
> a suitable message to pass on to its neighbor.
>> It's entirely unclear in our documents what functions belong to the KMP 
>> and what functions belong to the routing protocol.
>>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 13 May 2010 15:31:52 -0400 (Eastern Daylight Time)

So characterizing RSVP as a one-to-one protocol might be more appropriate 
for the purpose of determining cryptographic requirements and design 
goals if you don't intend to take on the larger problem of end-to-end 
protection of information that is changed en-route.

--Sandy

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 May 2010 15:53:00 -0400

Sandra> RSVP attempts to communicate information from end to end,
    Sandra> but each hop might modify that information in certain
    Sandra> defined ways.  RSVP-TE shares this behavior e.g., from
    Sandra> RFc5151:

    Sandra>    The ERO that a domain border node receives in the Path
    Sandra> message was supplied by the ingress node of the TE LSP and
    Sandra> may have been updated by other nodes (for example, other
    Sandra> domain border nodes) as the Path message was propagated.

Ah, I knew but forgot that.

Does my other point--namely that you may not know for a given path who
your downstream is until you send it--stand?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 16:07:30 -0400

I guess that depends upon what order you do the processing in.  To send 
an RSVP message onward, you have to consult the combination of any ERO 
in the message and your routing table.  Presumably, given the 
constraint, you do that before you "send" the message.  (You have to 
actually consult the routing table in the RSVP processing if there is an 
ERO, since if there is no route to the next (strict or loose hop, which 
one affecting the kind of check you have to do), you have to produce an 
RSVP-TE error.

Yours,
Joel

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 May 2010 06:13:53 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> I will leave the rest of the quesitons for others, but I want
    Joel> to comment on one of Sam's quesiton.

    Joel> We are not doing RSVP.  We are doing RSVP-TE.  

OK, if this is true, the design-guide should be updated to stop claiming
we are doing RSVP both in section 2 and later in the document.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 May 2010 09:53:34 -0400

Yep.  It should talk about RSVP-TE, but the only mention, if any, of 
RSVP, would be to say that it is out of scope for thee document.
We need to make sure this gets fixed in the next revision.

Yours,
Joel

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 14 May 2010 22:20:09 +0530

> It's entirely unclear in our documents what functions belong 
> to the KMP  and what functions belong to the routing protocol.
> 

Yup, routing protocols should be oblivious to how the traffic key has been generated. Its something that the KMP must do.

> access to keying material over time, especially as who has access

Yes, I agree that reasons such as limiting the amount of time that is available to attackers for breaking the keys or limiting the amount of traffic that's available for attackers that's protected using the same traffic key isn't correct. While, its true that crypto algorithms shouldn't be used for infinitely large number of operations, the limits are extremely large and possibly depends on the properties of the crypto modes rather than the algorithms themselves.

I will change the text to reflect this.

In addition to this, I will also update the document to refer to RSVP-TE instead of doing it for plain RSVP.

Cheers, Manav

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 May 2010 13:39:47 -0400

>>>>> "Bhatia," == Bhatia, Manav (Manav) <[email-masked]> writes:

    >> 
    >> I have one huge comment that came out of this review and the
    >> questions I raised.  It's entirely unclear in our documents what
    >> functions belong to the KMP and what functions belong to the
    >> routing protocol.
    >> 
    >> For example, if my routing protocol has a long-term key, and
    >> exchanges nonces and then generates a traffic key from the
    >> long-term key and the nonces, it is performing key-management
    >> functions.

    Bhatia,> Yup, routing protocols should be oblivious to how the
    Bhatia,> traffic key has been generated. Its something that the KMP
    Bhatia,> must do.

For the most part, I agree with the quoted sentence, but I do not
understand how it relates to my comment.  my comment.  Regardless of
where the KMP/RP boundary is, it remains roughly true that the RP is
oblivious to how its inputs are generated.

I used the words roughly and "for the most part," above because I think
there are some messy situations surrounding group keying and replay
avoidance that may play into this.  I'd prefer to handle the simple case
in this discussion before getting into that.