Early Review of draft-farrelll-mpls-opportunistic-encrypt-04
review-farrelll-mpls-opportunistic-encrypt-04-secdir-early-kaufman-2015-05-28-00

Request Review of draft-farrelll-mpls-opportunistic-encrypt
Requested rev. no specific revision (document currently at 05)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2015-05-28
Requested 2015-05-13
Other Reviews
Review State Completed
Reviewer Charlie Kaufman
Review review-farrelll-mpls-opportunistic-encrypt-04-secdir-early-kaufman-2015-05-28
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg05707.html
Reviewed rev. 04 (document currently at 05)
Review result Has Issues
Draft last updated 2015-05-28
Review completed: 2015-05-28

Review
review-farrelll-mpls-opportunistic-encrypt-04-secdir-early-kaufman-2015-05-28

Loa--
	I hope this is an appropriate distribution list. If not please
forward as necessary.

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.

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.

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.

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.

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.

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.

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"




	--Charlie

-----Original Message-----
From: secdir [

mailto:secdir-bounces

 at ietf.org] On Behalf Of Loa Andersson
Sent: Friday, May 08, 2015 5:24 AM
To: secdir; draft-farrelll-mpls-opportunistic-encrypt at tools.ietf.org;
mpls-chairs at tools.ietf.org
Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt

Security Directorate,

Apologies if I'm sending this too wide!

The MPLS wg has a review team. The task of the review team is to support the
wg chair, in particular when we are considering a wg adoption poll.

Before starting a wg adoption poll we run all documents through the MPLS-RT
review (you can find a typical invite to such a review below).

Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT
review. We have enough reviewers accepting to do the review, but all of them
have flagged that they are not entirely comfortable reviwing the document
from a security perspective. Stephen have very graciously offered to help if
there are question.

I still would like to ask if it possible to find an expert reviewer in the
security directorate. Questions asked are the same as you find in the invite
below.

Please contact me if you are willing to review the document for us.

/Loa
mpls wg co-chair

-----------example of mpls-rt review invite -----------------------

Dave, Mach, Lizhong and Kamran,


You have be selected as MPLS-RT reviewers for
draft-farrelll-mpls-opportunistic-encrypt.

Note to authors: You have been CC'd on this email so that you can know that
this review is going on. However, please do not review your own document.

Note to the reviewers: I understand that this document is very much on the
"security side of the house", however I will also reach out to the Sec-Dir
for a more security biased review.
This should not stop you from commenting on security aspects of the draft,
but if you feel like it I'm comfortable with a "normal MPLS-RT review",
responding to questions below.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is the
document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn't have to
be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments may be
sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
*really* need to be resolved before adopting it as a working group document,
and what can wait until the document is a working group document and the
working group has the revision control.

Are you able to review this draft by May 17, 2015? Please respond in a
timely fashion.


Thanks, Loa
(as MPLS WG chair)


/Loa
-- 



Loa Andersson                        email: loa at mail01.huawei.com
Senior MPLS Expert                          loa at pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
secdir mailing list
secdir at ietf.org


https://www.ietf.org/mailman/listinfo/secdir


wiki: 

http://tools.ietf.org/area/sec/trac/wiki/SecDirReview