Subject: [BEHAVE] address-format secure configuration

From: "David Harrington" <[email-masked]>
Date: Wed, 31 Mar 2010 13:11:52 -0400

Hi,

I think section 4.2 Secure Configuration is inadequate. The discussion
of configuration is inadequate, and the discussion of security is
inadequate.

Configuration will require some synchronization if the values should
change. Specifying a default prefix might provide an initial
synchronization, but does not address the difficult operational issue
of synchronization of changes to the deployed prefixes and formats.
The document does not discuss the operational and security
vulnerabilties exposed during the process of changing a prefix. 

Secure configuration of prefixes and formats across multiple devices
and applications in a network will require some type of authentication
and authorization, and protection from various possible attacks, such
as man in the middle attacks. A default prefix does not address the
security issues involved in secure configuration, as far as I can see.

I think work needs to be done on this section. I recommend addressing
the operational considerations of deploying a change of prefix across
a network, and separately identifying and addressing the threats
involved in prefix configuration.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 31 Mar 2010 12:35:29 -0700

Configuring the translator's prefix in the devices is akin to configuring the
IPv6 prefix used by IPv6's stateless autoconfiguration.  

Is there guidance in RFCs on how to securely configure a network's IPv6
prefix, and how to change it when renumbering the network?  That text could be
pulled into the address-format document or, better yet, cited.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, March 31, 2010 10:12 AM
> To: [email-masked]
> Subject: [BEHAVE] address-format secure configuration
> 
> Hi,
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Mar 2010 20:56:42 +0000

David,

We do not describe configuration in this document, we merely describe address format. Configuration is indeed important, but do you really believe that it should be part of this document? What about the other documents in the working set, e.g. the description of stateful and stateless address translation? Or the framework document? The note in the security section is meant to flag the issue, not to resolve it.

-- Christian Huitema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Wednesday, March 31, 2010 10:12 AM
To: [email-masked]
Subject: [BEHAVE] address-format secure configuration

Hi,

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Wed, 31 Mar 2010 21:16:24 +0000

To second what Christian said, if you look at RFC 4291 it contains
no discussion of secure configuration, it defines address formats.
This draft is no different.

Configuration mechanisms are outside the scope of this document.
I don't believe the things you raise belong in this document.
They could be in a separate document for which we could add a
milestone as part of the rechartering.

-Dave

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christian Huitema
> Sent: Wednesday, March 31, 2010 1:57 PM
> To: David Harrington; [email-masked]
> Subject: Re: [BEHAVE] address-format secure configuration
> 
> David,
> 
> We do not describe configuration in this document, we merely describe
> address format. Configuration is indeed important, but do you really
> believe that it should be part of this document? What about the other
> documents in the working set, e.g. the description of stateful and
> stateless address translation? Or the framework document? The note in
> the security section is meant to flag the issue, not to resolve it.
> 
> -- Christian Huitema
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Apr 2010 10:46:48 +1300

I agree, it doesn't belong here, but it is important. Some of the issues
and mechanisms are covered in draft-carpenter-renum-needs-work-05.txt, which
is now in the RFC Editor queue (having passed the IESG as a direct submission
to one of the Ops ADs). The topic probably belongs in v6ops IMHO.

Regards
   Brian Carpenter

On 2010-04-01 10:16, Dave Thaler wrote:
>> Behalf Of David Harrington

---

From: "David Harrington" <[email-masked]>
Date: Wed, 31 Mar 2010 18:24:48 -0400

Hi,

I raised the issue of secure configuration because the document does.

I probably wouldn't really have noticed this section much except that
the section asserts that using a default prefix addresses security
concerns, and I disagree with that.

I would be fine with pointers to other documents, such as
draft-carpenter-renum-needs-work, and maybe v6 autoconfig documents
and/or DHCP security.
I would be fine with a pointer to one of the behave documents that
addresses the concern, or
to a v6ops document that addresses the concern. 
(I think but might change my mind) I would even be fine with a
statement that this document only defines address formats and does not
create any new security concerns.

But to observe in the security considerations that multiple devices
and applications need to be configured consistently and securely, and
then not provide any guidance or pointers to guidance seems wrong to
me.

dbh

> From: Dave Thaler [mailto:[email-masked]] 
> Sent: Wednesday, March 31, 2010 5:16 PM
> To: David Harrington
> Cc: Christian Huitema; [email-masked]
> Subject: RE: [BEHAVE] address-format secure configuration
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Apr 2010 00:24:09 +0000

Do you want to replace the security section by a simple statement that "This document only defines address formats and does not create any new security concerns?"

We can certainly do that, but I would rather make sure that the concerns that we raise get documented somewhere. Clearly, address translation opens interesting opportunities for address spoofing and "interesting" configurations. 

Spoofing is mostly an issue with stateless address translation, which allows nodes to specify in an IPv6 address the IPv4 translation. We may want to move that text to the "stateless translation" draft. Prefix configuration is an issue with any time of translation, and should probably be addressed in the framework document.

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Wednesday, March 31, 2010 3:25 PM
To: Dave Thaler
Cc: Christian Huitema; [email-masked]
Subject: RE: [BEHAVE] address-format secure configuration

Hi,

dbh