[dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

[Ralph Droms <[e-mail]>]

Bernie - thanks for your review and feedback on the IPsec for relay agent 
draft.

I had not intended the text in section 4 to require an unbroken chain of 
IPsec forwarding (although not using IPsec over every link doesn't make 
much sense).  Are you referring to the following text:

    If a client message is relayed through multiple relay agents,
    each of the relay agents must have established independent, pairwise
    trust relationships.  That is, if messages from client C will be
    relayed by relay agent A to relay agent B and then to the server,
    relay agents A and B must be configured to use IPSec for the messages
    they exchange, and relay agent B and the server must be configured to
    use IPSec for the messages they exchange.

I intend the text to describe the use of hop-by-hop IPsec, without an 
absolute requirement that all hops use IPsec.  Not being able to anticipate 
every possible deployment, I suggest "SHOULD use IPsec on every hop", with 
some appropriate word-smithing of the spec for clarification.

- Ralph

At 02:33 PM 10/28/2002 -0600, Bernie Volz (EUD) wrote:

>Ralph:
>
>Looks like you've been a bit busy!
>
>Regarding this draft, does it make sense when multiple relays are involved to
>disallow (MUST?) a relay agent from forwarding using IPSec if the relay
>received the relayed client message without IPSec? (This might also have been
>a good restriction to add to the DHCPv6 specification.) One potential issue
>with this is that it would require code changes in the relay or some 
>filtering
>rules in the stack to assure non-protected relay messages are not 
>processed. But
>if you don't have it, security could easily be compromised since an 
>attacker can
>just set up a relay-chaining arrangement.
>
>Note that by your description in Section 4, this is already stated but 
>perhaps
>not as clearly as it should be.
>
>Also, we should move to make this a Working Group item. Any objections?
>
>- Bernie
>
>-----Original Message-----
>From: [e-mail] 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Monday, October 28, 2002 6:27 AM
>Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : Use of IPsec for Securing DHCPv4 Messages 
> Exchanged
>                           Between Relay Agents and Servers
>         Author(s)       : R. Droms
>         Filename        : draft-droms-dhcp-relay-agent-ipsec-00.txt
>         Pages           : 4
>         Date            : 2002-10-25
>
>'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP
>messages exchanged between relay agents and servers are not subject
>to attack.  This document describes how IPsec can be used to protect
>messages exchanged between relay agents and servers.
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-00.txt>http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-00.txt 
>
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-droms-dhcp-relay-agent-ipsec-00.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>or 
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [e-mail].
>In the body type:
>         "FILE /internet-drafts/draft-droms-dhcp-relay-agent-ipsec-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg