Last Call Review of draft-ietf-mif-problem-statement-
review-ietf-mif-problem-statement-secdir-lc-salowey-2010-08-25-00

Request Review of draft-ietf-mif-problem-statement
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-08-24
Requested 2010-08-16
Authors Pierrick Seite, Marc Blanchet
Draft last updated 2010-08-25
Completed reviews Secdir Last Call review of -?? by Joseph Salowey
Assignment Reviewer Joseph Salowey
State Completed
Review review-ietf-mif-problem-statement-secdir-lc-salowey-2010-08-25
Review completed: 2010-08-25

Review
review-ietf-mif-problem-statement-secdir-lc-salowey-2010-08-25

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document discusses a problem statement about a single host
supporting multiple interfaces and configuration associated with those
interfaces.   The document does have a security considerations section,
however I think it could benefit from more security discussion.  Here
are a few suggestions:

1) Lower layer authentication and encryption

It's possible that some interfaces may have link layer or IP layer
encryption and authentication.  Its possible that this characteristic
might be used in determining how configuration parameters are processed.
Some connection managers may already do this to a certain extent.  I
think this should be listed as a consideration in the appropriate
sections of the document (3.1, 3.6,5)

2) I think the security considerations can be expanded

It discusses that information may be leaked from one network to another
which seems to be talking about generic data.  This is true, but it
seems that would be worthwhile to talk specifically about the
information discussed in the document.  For example it seems that it is
at least possible for one interface to send configuration parameters
that will cause a denial of service on another interface.  It may also
be possible for one host to set configuration parameters which cause
certain traffic to be forwarded to an attacker.  

The last paragraph is also not very clear.  What I think you are trying
to say is that the information that is used by the connection manager
may be vulnerable to spoofing and forgery if it is unprotected.  In
general its not possible to protect this information in all cases, so it
is not clear what you are recommending.  

Cheers,

Joe