Re: [BEHAVE] address-format secure configuration

["David Harrington" <[e-mail]>]

 > We can certainly do that, but I would rather make sure that 
> the concerns that we raise get documented somewhere.

I would like two things:
1) the statement that default prefixes solve this problem needs to be
reworded, since it seems obvious that default prefixes alone do not
provide secure or synchronized configuration, especially for prefix
changes. I think the current section doesn't adequately identify the
issues that should be considered, so the rewording should mention the
synchronization and security issues in a **bit** more detail.
2) the secure configuration section of the current document should
point to documents where the concerns raised by address translation
get discussed in more detail, and preferably operational guidance is
provided in those documents. The documents might be other behave
documents or v6ops documents or other documents.

I think those changes should be fairly simple.

dbh

> -----Original Message-----
> From: Christian Huitema [mailto:[e-mail]] 
> Sent: Wednesday, March 31, 2010 8:24 PM
> To: David Harrington; Dave Thaler
> Cc: [e-mail]
> Subject: RE: [BEHAVE] address-format secure configuration
> 
> 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
> > 
> > 
> 
> 
>