The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
draft-ietf-dhc-auth-suboption-05

Allison, here is the answer that Ted Lemon sent regarding your discuss.  Retransmission is properly covered in the DHCP draft, and it is not up to a subagent to decide how/when retransmission will happen.  Does this resolve your issue, or do you think we need changes to this document?

>Cc: Mark Stapp , Allison Mankin ,
> Ralph Droms
>From: Ted Lemon
>Subject: Re: New version of draft-ietf-dhc-auth-suboption-05.txt
>Date: Thu, 26 Aug 2004 12:16:32 -0500
>To: Margaret Wasserman ,
> Thomas Narten
[...]
>Anyway, the handling of exponential backoff is orthogonal to this draft - this just describes the format of a DHCP option and the way it's used.  The DHCP draft (RFC2131) does specify the use of exponential backoff, so a correct implementation will not have the problem Alison asked about, although tragically there is no shortage of incorrect implementations that retransmit much too frequently.
>
>How would you like this dealt with?  Do you think we need additional verbiage in the draft because implementors of RFC2131 aren't unanimous in their current support of exponential backoff?  We could, for example, remind readers that RFC2131 requires exponential backoff, and explain why it's important in this case.
>
>However, since relay agents don't drive the protocol (they don't choose when to retry) there is still the problem that a reader of this draft is probably not in a position to do anything about the retry frequency problem.  Requiring that the relay agent drop too-frequent retries would address this problem, but historically we've tried to avoid requiring relay agents to maintain state about clients.
>

Latest draft seems to address Thomas' discuss, but not Allison's.  Sent note to Thomas requesting review and to authors requesting status of changes to address Allison's issue (exponential back off for UDP retries).

Sent message to authors requesting clarification on how/if discuss issues have been addressed:

To: Ted Lemon , Mark Stapp
From: Margaret Wasserman
Subject: draft-ietf-dhc-auth-suboption-04.txt
Cc: Allison Mankin

Hi Ted and Mark,

There has been an update to draft-ietf-dhc-auth-suboption-04.txt, but I couldn't find how/where it addresses the remaining discuss comments from Allison and Thomas (included below).

If you intended for the new version to address Allison's and Thomas' comments, could you please explain how they have been addressed?  If you have not addressed them yet, when should we expect a new version that does address them?

Thanks,
Margaret

Allison Mankin:
Discuss:
[2004-02-19]  

My earlier issues about stating the applicability of this suboption
versus the IPsec suboption have been handled (though see non-blocking
comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

In addition, are client retries exponentially backed off?  Otherwise use
of this suboption by many clients in any bursty event has the
potential to cause a congestion problem.  Surge of sends, a significant
number experience the relay misordering and get dropped,
and the retries kick in from many clients.  If retransmissions
are backed-off, little problem.  If not, besides congestion, there are
also likely to be more replay drops.

So when clients implement this sub-option, it's suggested they
update their retransmission.

Comment:
[2004-02-19] Is there still a difference between DHCP, and say SIP, in whether a
vendor must implement security mechanisms such as these
sub-options?

Thomas Narten:
Discuss:
[2004-02-19] >    All implementations MUST support Algorithm 1, the HMAC-MD5

>    algorithm. Additional algorithms may be defined in the future,
>    following the process described in Section 12.

Note: HMAC-SHA1 is considered to be superior to HMAC-MD5, so is
preferred. Is there a reason to support HMAC-MD5 at all? If there is
no installed base to interoperate with, it would be preferable to just
use HMAC-SHA1.

There are a couple of places early on where the document suggests that
the authentication check only covers the relay agent options (as
opposed to all including those supplied by the client). Later, it is
clear that the entire packet (excluding the fields that change). Would
be good to fix  the earlier wording. E.g.,:

>    The Authentication suboption is included by relay agents that wish
>    to ensure the integrity of the data they include in the Relay Agent
>    option.


>    The goal of this specification is to define methods that a relay
>    agent can use to:
>      1.  protect the integrity of the data that the relay adds

[Ballot discuss]
>    All implementations MUST support Algorithm 1, the HMAC-MD5
>    algorithm. Additional algorithms may be defined in the future,
>    following the process described in Section 12.

Note: HMAC-SHA1 is considered to be superior to HMAC-MD5, so is
preferred. Is there a reason to support HMAC-MD5 at all? If there is
no installed base to interoperate with, it would be preferable to just
use HMAC-SHA1.

There are a couple of places early on where the document suggests that
the authentication check only covers the relay agent options (as
opposed to all including those supplied by the client). Later, it is
clear that the entire packet (excluding the fields that change). Would
be good to fix  the earlier wording. E.g.,:

>    The Authentication suboption is included by relay agents that wish
>    to ensure the integrity of the data they include in the Relay Agent
>    option.


>    The goal of this specification is to define methods that a relay
>    agent can use to:
>      1.  protect the integrity of the data that the relay adds

[Ballot discuss]
My earlier issues about stating the applicability of this suboption
versus the IPsec suboption have been handled (though see non-blocking
comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

In addition, are client retries exponentially backed off?  Otherwise use
of this suboption by many clients in any bursty event has the
potential to cause a congestion problem.  Surge of sends, a significant
number experience the relay misordering and get dropped,
and the retries kick in from many clients.  If retransmissions
are backed-off, little problem.  If not, besides congestion, there are
also likely to be more replay drops.

So when clients implement this sub-option, it's suggested they
update their retransmission.

[Ballot discuss]
My earlier issues about stating the applicability of this suboption
versus the IPsec suboption have been handled (though see non-blocking
comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

In addition, are client retries exponentially backed off?  Otherwise use
of this suboption by many clients in any bursty event has the
potential to cause a congestion problem.  Surge of sends, a significant
number experience the relay misordering and get dropped,
and the retries kick in from many clients.  If retransmissions
are backed-off, little problem.  If not, besides congestion, there are
also likely to be more replay drops.

So when clients modify to implement this sub-option, can they
check their retransmission?

[Ballot discuss]
Because relay agents are
  involved when clients reboot, periods of very high reboot activity
  will result in the largest number of messages which have to be
  signed and verified. During a cable MSO head-end reboot event, for
  example, the time required for all clients to be served may increase.

My earlier issues about stating the applicability of this suboption
versus the IPsec suboption have been handled (though see non-blocking
comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

In addition, are DHCP retries exponentially backed off?  Otherwise use
of this suboption by many clients when a server first comes up has the
potential to cause a congestion problem.  Surge of sends, a number
delayed in processing and dropped, synchronized, quick retries lead to
another round of congestion and more drops.

May be useful here:  a small random +/- on the time of "late"  delivery 
at which the replay drop is performed.  (If the security experts don't
raise a concern).

[Ballot discuss]
Because relay agents are
  involved when clients reboot, periods of very high reboot activity
  will result in the largest number of messages which have to be
  signed and verified. During a cable MSO head-end reboot event, for
  example, the time required for all clients to be served may increase.

My earlier issues about stating the applicability of this suboption
versus the IPsec suboption have been handled (though see non-blocking
comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

There could be a liveness problem if the both first tries and retries often
have misorderings. 

In addition, are the retries exponentially backed off?  Otherwise use of this suboption by many clients when a server first comes up has the potential to cause a congestion problem.

Possible remedy:  a small random factor on how "late"  delivery is OK before the replay drop is performed.  (If the security people would say yes).

[Ballot comment]
Is there still a difference between DHCP, and say SIP, in the question of whether a vendor must implement security mechanisms such as these sub-options?

[Ballot discuss]
Because relay agents are
  involved when clients reboot, periods of very high reboot activity
  will result in the largest number of messages which have to be
  signed and verified. During a cable MSO head-end reboot event, for
  example, the time required for all clients to be served may increase.

My earlier issues about stating the applicability of this suboption versus the IPsec suboption have been handled (though see non-blocking comment).

Below is a Transport Discuss.


13.1 Protocol Vulnerabilities

  Because DHCP is a UDP protocol, messages between relays and servers
  may be delivered in a different order than the order in which they
  were generated. The replay-detection mechanism will cause receivers
  to drop packets which are delivered 'late', leading to client
  retries. The retry mechanisms which most clients implement should
  not cause this to be an enormous issue, but it will cause senders to
  do computational work which will be wasted if their messages are
  re-ordered.

There could be a liveness problem if the both first tries and retries often
have misorderings. 

In addition, are the retries exponentially backed off?  Otherwise use of this suboption by many clients when a server first comes up has the potential to cause a congestion problem.

Possible remedy:  a small random factor on how "late"  delivery is OK before the replay drop is performed.  (If the security people would say yes).

[Ballot comment]
The draft contains the following text in Section 11:

  DHCP servers may interact with multiple relay agents. Server
  implementations MAY support configuration that associates the same
  algorithm and key with all relay agents. Servers MAY support
  configuration which specifies the algorithm and key to use with each
  relay agent individually.

This key management choices are not then discussed in the Security
Considerations section.  Since that section does discuss the choice
between using the IPSec mechanism for authentication (with
its related key management implications), it seems like it would be
useful to mention it there.  This is particularly true because of the
Security considerations text here:

  If IPsec is not available or there are multiple relay agents for which
  multiple keys must be managed, the protocol described in this
  document may be appropriate.

[Ballot discuss]
The Introduction says that the goal of the document is integrity protection
  and replay protection, while leveraging existing mechanisms.  The Abstract
  talks about authentication and integrity protection.  These need to be
  harmonized.

[Ballot comment]
This document uses 'signature' improperly.  See the definition of 'digital
  signature' in RFC 2828.  The discussion under "$ message authentication
  code vs. Message Authentication Code (MAC)" may help the authors select a
  better word.  I am willing to let the current usage stand for compatibility
  with previously published documents.  I would really like to see a paragraph
  added to the terminology discussion that makes it clear what 'signature'
  means in this document.
 
  The 'DISCUSSION' paragraph in section 7.1 ought to be in the Security
  Considerations.

  Please change 'IPSEC' to 'IPsec' (the title of the referenced document
  will be changed to reflect this convention prior to publication).

[Note]: 'This document will need to have wording added (similar to what we are planning to add to draft-ietf-dhc-relay-agent-ipsec) to explain the relationship between the two relay agent authentication choices.

In the meantime, I would like to get this document reviewed so that we can determine if there are any technical (or other) issues that need to be resolved before publication.' has been cleared by Margaret Wasserman

[Note]: 'This document will need to have wording added (similar to what we are planning to add to draft-ietf-dhc-relay-agent-ipsec) to explain the relationship between the two relay agent authentication choices.

In the meantime, I would like to get this document reviewed so that we can determine if there are any technical (or other) issues that need to be resolved before publication.' added by Margaret Wasserman

[Note]: 'This document will need to have wording added (similar to what we are planning to add to draft-ietf-dhc-relay-agent-ipsec) to explain the relationship between the two relay agent authentication choices.' added by Margaret Wasserman