Authentication of DHCP Relay Agent Options Using IPsec
draft-ietf-dhc-relay-agent-ipsec-02

From the OPS Directorate review:

High order bit: This draft needs to be more specific with respect to the
intended IPsec and IKE usage.

Section 6

This draft references only IPsec documents such as RFC 2401 and 2406, but
not IKE, which is odd since it does say that IKE with preshared secrets
SHOULD be supported.  In places there is confusion as to how keys are to
be derived (manually or dynamically).  For example, in Section 8 it seems
to imply that manual keying MUST be supported.

"Relay agents and servers can use IPsec mechanisms [3] to exchange
   messages securely as described in this section."

What specific IPsec security properties are required?  Support for ESP
with non-null transform?  Support for ESP with null transform? Support for
AH? Replay protection?

"If there is a single
relay agent between the DHCP client, there MUST be an IPsec trust
relationship established between the relay agent and the DHCP server."

What are we saying here?  That there needs to be a manual key put in place
for use with IPsec?  If so, what are the SA parameters to be used?  Or are
we trying to say that IKE is to be used with any of the authentication
modes? I'm not sure.

"   In Figure 1, relay agent A and the DHCP server must have an IPsec
   session through which DHCP messages are exchanged."

It would be more specific to talk about setup of IKE Phase 1 and Phase 2
SAs if that is what is intended.

The draft could use a paragraph on IKE identifier payloads specifying
which ones are REQUIRED for implementation.  Also it would be helpful to
state which MODES are required.  Tunnel mode? transport mode? Aggressive
Mode? Main Mode?

  SecDir Review was conducted by Steve Bellovin and Steve Kent.
  Steve Bellovin had a DISCUSS on an earlier version of this document
  regarding replay protection.  Not all of those concerns have been
  adequately addressed.  Steve Kent uncovered a few concerns regarding
  alignment with 2401bis and the other IPsec documents that are in the
  RFC Editor queue.  While my comments are long, I believe that most
  are very simple to address.  One or two points may require dialogue.

  The document Introduction says that the goals are:
  >
  > 1.  protect the integrity of the data that the relay adds
  > 2.  provide replay protection for that data
  > 3.  leverage the existing IPsec mechanism
  >
  I think that you are also trying to authenticate the relay agent as
  the source of the data.

  In section 4, 3rd paragraph, please change "privacy" to 
  "confidentiality."

  In section 4, There are many other forms of DoS attack.  I suggest
  that this text ought to say that the ones discussed are samples.
  Consider this one: the attacker can assign false DNS servers, with
  obvious bad consequences.

  In section 5, 1st paragraph, please change "IPsec trust relationship"
  to "IPsec security association (SA)."

  In section 5, Selectors discussion, a traffic selector consist of the
  address AND UDP (as the protocol) AND the well-known ports for the
  targets.  The current wording leads the reader to believe that the
  selectors are only the addresses, which is incorrect.

  In section 5, key Management discussion, says:
  >
  > IKE [4] with preshared secrets must be used.
  >
  s/must/MUST/
  
  It also says:
  >
  > DHCP messages ... should only be accepted from DHCP peer
  >
  s/should/SHOULD/
  And, why isn't this a MUST?
        
  Third, it is fair to say that pre-shared secrets are sufficient when
  working in a small, single administration context; however, the
  ephemeral Diffie-Hellman exchange used by IKE is useful and desirable
  even in this context.  Since it is ephemeral, it does not add to the
  administrative burden.

  Fourth, I'm concerned about the qualifier "If replay protection...."
  Replay protection is identified as a goal in the Introduction.  Please
  reword this portion mandate implementation; however, implementations
  SHOULD support manual keying for environments where replay protection
  is not needed.  Please see the analysis in RFC 3562 regarding preshared
  secrets.

  Fifth, more detail on IKE options needs to be specified.  The document
  does not specify which modes ought to be used, what identity forms are
  to appear in certificates when they are used, which forms of public key
  authentication must be supported, and so on.  Please look at RFC 3788,
  section 5, for an example of how to specify IKE usage.

  In section 7, I would like to see a SHOULD use IKE.  This relates to
  the above point on section 5 that an ephemeral Diffie-Hellman exchange
  used by IKE is useful and desirable.

  Second, the references to [12] is good, but the section should talk
  about residual vulnerabilities.  In particular, attacks on the link
  between the client and the first relay agent need to be discussed. 
  Also, please state the reasons that link-layer security does not solve
  all of the problems being discussed.

  Please reference the updated IPsec documents, like 2401bis.  All of
  these documents are in the RFC Editor queue.

Is replay protection a requirement or not?  If so, IKE needs to be a MUST rather than a SHOULD.