Re: [secdir] [mpls] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt

["Adrian Farrel" <[e-mail]>]

Charlie,

Thanks for this. Forgive me for stumbling through the security aspects: I'm sure
Stephen will pick me up on whatever I get wrong.

> All--
> Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a
> protocol for doing opportunistic encryption of MPLS connections. It permits
> encryption at any of two scopes: between adjacent Label Switching Routers
> (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an
> LSP. Opportunistic encryption in this case means that there is no mechanism
> specified for authenticating the endpoints of the encrypted channel. The two
> endpoints do an anonymous Diffie-Hellman exchange and use the resulting key
> to encrypt the connection. The protocol is not protected from a
> man-in-the-middle attack (though some mechanisms for detecting such an
> attack after the fact are suggested and a keying infrastructure could be
> added later).
>
> The encryption aspects of the protocol seem well thought out and
> appropriate. The question at hand is whether to adopt this document as a
> working group document and it easily meets that bar (at least from a
> security standpoint). I have a number of questions about operational aspects
> of the protocol (perhaps due to my limited understanding of MPLS) and I have
> some suggestions for enhancements that will probably be necessary eventually
> and might be easier to make before there is widespread deployment:
>
> There is an issue that came up in the design of IKEv2 that may be an issue
> here as well. I don't know whether MPLS connections are bi-directional or
> whether separate connections need to be established in the two directions.
>
> If they are bi-directional, then there are race conditions that can occur if
> both ends attempt to initialize a connection simultaneously and there must
> be some tie-breaking mechanism to assure that exactly one of the connection
> attempts succeeds. If they are uni-directional, and if the connection is
> always initialized by the sending end, then this is not a problem (though it
> is replaced with the problem that messages of this protocol sent in the
> reverse direction cannot be tunneled over the MPLS connection). (This
> document seems to imply that MPLS connections can be either uni-directional
> or bi-directional, but I don't understand MPLS well enough to have
> understood it). Even if the connections are bi-directional, it will make
> your life simpler if you use different symmetric keys in the two directions.
> This can be done easily by getting two independent keys from the key
> expansion process.

Right. LSPs may be unidirectional or bidirectional.

Section 4 and particularly 4.3 describe how the return path is selected for the
case of a unidirectional LSP.

So we have four questions:

1. Is the return path secure?
2. Who initiates the use of OS?
3. How do we handle race conditions?
4. Should we have different keys in different directions?

In fact, the key exchange does not itself need to be secure, but it would be
better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it
will likely not be possible in the case of OS. So that's Q1.

In the case of a unidirectional LSP, only the source node (i.e. upstream from
the perspective of data flow) can be the initiator for the key exchange because
the key exchange requires the use of a message flowing on the LSP itself. So,
for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3.

But, in fact, a bidirectional LSP is in fact (from the point of view of the
forwarding plane) the association of two unidirectional LSPs. The association
may be so tight (in the control plane or the management plane, and with fate
sharing) that the LSP is referred to as *a* single bidirectional LSP, but that
doesn't change the forwarding plane behavior. And, indeed, in the bidirectional
case, there is no reason to not have encryption in one direction and not in the
other direction (except, of course, that more is better :-).  So that means that
each direction of the bidirectional LSP is responsible for initiating its own
OS. 

Hence Q3 is not a problem, and Q4 takes care of itself.

We should definitely clarify this in the draft (and thank you for making me
describe it here), but I'd like some more discussion with the WG to check I am
right about this.

> A second issue relates to algorithm negotiation. While the protocol allows
> for any of the crypto algorithms to be replaced, and the algorithms are
> indicated on the wire, it does not appear to allow for a smooth upgrade
> where the two ends are updated independently and everything must continue
> to work when only one end has been updated. To accomplish that, there
> should be an algorithm negotiation (as takes place in IKE and TLS) where one
> end presents a list of algorithms is can support and the other end chooses the
> algorithms it prefers. A simpler variation would be for a responder to be
> able to reject the algorithms assumed by the initiator and send back a list
> of algorithms it will accept. Note: it's possible that MPLS already operates
> with the restriction that the two ends of a connection must be consistent
> and operations will halt if the two ends are updated non-simultaneously. If
> that's true, then adding crypto doesn't make the situation any worse and it
> would be acceptable to continue to operate that way.

I'm so far from being an expert in this matter that I am probably making a fool
of myself (again), but is algorithm replacement actually any different from key
change? That is, the key negotiation protocol negotiates the key and algorithm
to use and so can also negotiate changes in both key and algorithm. 

Section 4.2.3 mentions this, but is exceptionally week. I'll add some text
(assuming what I just wrote is not complete lunacy).
The key ID identifies the key and the algorithm in one field, so being able to
change the key ID was intended to also allow changing the algorithm.

> A possible problem with Key Identifiers: the Key Identifier is only 4 bits
> long, which should be sufficient because at most two keys should be active
> at any given time. The Key Identifier, however, is chosen effectively
> randomly, which means that one time in 16 it will be the same as the Key
> Identifier it is replacing. While the protocol could be modified to do
> something special in that last (like adding one to the Key Identifier if it
> matches the previous value or redoing the key negotiation in that case), it
> would probably be better to get the Key-ID from the key expansion when
> there is no previous connection and add one (mod 16) when rekeying.

Yes, I had assumed that if the key ID was reselected then some form of secondary
choice would be made. Not sure that the predictability of simply adding one is
good idea (not that I can think of  specific associated risk).

> There is mention of the possibility of reusing g^i and g^r between
> connections. Some crypto purists would object to that, but I wouldn't. If
> you want to allow implementations that option, however, you should also
> include in the exchange nonce values Ni and Nr that are not reused between
> connections rather than depending on unique values for the other parameters
> to prevent reuse of keys.

Ah, hmm, OK.
Stephen?
Help!

> In section 3.5 (MTU considerations), I suspect you may be underestimating
> the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad
> bytes to make the encrypted payload size a multiple of 16 bytes. There are
> algorithm variants that do not add any padding, but they are somewhat
> controversial and difficult to implement in hardware. Further, the total
> overhead will be dependent of the crypto algorithm chosen, and the text
> should indicate that so that readers don't assume that there is some maximum
> number of bytes that can be wired into protocols that run above this.

That's helpful.
Stephen, I need you to help with this.

> I would suggest that most or all of sections 5 and 7 should be moved to
> Security Considerations. Failing that, the Security Considerations section
> should reference them.

Thanks. Since 5 is growing, I've put  back pointer from 6.
7.1 is already referenced from 6.2 and 6.3

> Typos:
>
> P4: "and if may be advisable" -> "and it may be advisable"
> P4: "an alternative key derivation functions" -> "alternative key derivation
> functions"
> P5: "key definition function" -> "key derivation function"
> P5: "attck vecotrs" -> "attack vectors"
> P5: "descirption" -> "description"
> P19: "opostie" -> "opposite"

Good.

vmt
Adrian