Re: [BEHAVE] address-format secure configuration

[Christian Huitema <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, March 31, 2010 3:25 PM
To: Dave Thaler
Cc: Christian Huitema; [e-mail]
Subject: RE: [BEHAVE] address-format secure configuration

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

> -----Original Message-----
> From: Dave Thaler [mailto:[e-mail]] 
> Sent: Wednesday, March 31, 2010 5:16 PM
> To: David Harrington
> Cc: Christian Huitema; [e-mail]
> Subject: RE: [BEHAVE] address-format secure configuration
> 
> 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
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Christian Huitema
> > Sent: Wednesday, March 31, 2010 1:57 PM
> > To: David Harrington; [e-mail]
> > 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
> > 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of David Harrington
> > Sent: Wednesday, March 31, 2010 10:12 AM
> > To: [e-mail]
> > Subject: [BEHAVE] address-format secure configuration
> > 
> > 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
> > [e-mail]
> > [e-mail]
> > [e-mail]
> > 
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> > 
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> 
>