Subject: Re: [BEHAVE] address-format secure configuration

From: Xing Li <[email-masked]>
Date: Thu, 01 Apr 2010 16:59:02 +0800

Christian Huitema 写道:
> 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.
>   

The current framework document reads

7. Security Considerations

"This document is the framework of IPv4/IPv6 translation. The
security issues are addressed in individual IPv4/IPv6 translation
documents, i.e. [I-D.ietf-behave-address-format],
[I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful],
[I-D.ietf-behave-dns64], and [I-D.ietf-behave-ftp64]."

The current xlate document reads

6. Security Considerations

"There are potential issues that might arise by deriving an IPv4
address from an IPv6 address - particularly addresses like broadcast
or loopback addresses and the non IPv4-translatable IPv6 addresses,
etc. The [I-D.ietf-behave-address-format] addresses these issues."

Should we change this format?

regards,

xing, congxiao

> -----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,
>
> 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:[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
>>
>> 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: [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
>>>
>>>
>>> -----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,
>>>
>>> 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]
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>       
>>     
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Apr 2010 01:16:16 +1300

I understood Dave to be commenting on a dangling reference
in the specific text in the address format draft. That is a
reasonable comment, since dangling references are always bad.
My personal view (already expressed) is that the particular point
is more of a v6ops question, but I didn't see Dave raising a
general point about the whole set of documents.

Regards
   Brian Carpenter

On 2010-04-01 21:59, Xing Li wrote:
> Christian Huitema 写道:
>> 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.
>>   
> 
>> From: David Harrington [mailto:[email-masked]] Sent: Wednesday,
>> March 31, 2010 3:25 PM
>> To: Dave Thaler
>> to a v6ops document that addresses the concern. (I think but might
>> change my mind) I would even be fine with a
>>> From: Dave Thaler [mailto:[email-masked]] Sent: Wednesday,
>>> March 31, 2010 5:16 PM
>>> To: David Harrington

---

From: "David Harrington" <[email-masked]>
Date: Thu, 1 Apr 2010 09:21:51 -0400

> 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

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Wednesday, March 31, 2010 8:24 PM
> To: David Harrington; Dave Thaler
> Cc: [email-masked]
> 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.
>