Re: [BEHAVE] address-format secure configuration

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:ietfdbh@comcast.net] 
> Sent: Wednesday, March 31, 2010 3:25 PM
> To: Dave Thaler
> Cc: Christian Huitema; behave@ietf.org
> 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:dthaler@microsoft.com] 
>> Sent: Wednesday, March 31, 2010 5:16 PM
>> To: David Harrington
>> Cc: Christian Huitema; behave@ietf.org
>> 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: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
>>> Behalf Of Christian Huitema
>>> Sent: Wednesday, March 31, 2010 1:57 PM
>>> To: David Harrington; behave@ietf.org
>>> 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: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
>>> Behalf Of David Harrington
>>> Sent: Wednesday, March 31, 2010 10:12 AM
>>> To: behave@ietf.org
>>> 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
>>> dbharrington@comcast.net
>>> ietfdbh@comcast.net
>>> dharrington@huawei.com
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> Behave@ietf.org
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> Behave@ietf.org
>>> https://www.ietf.org/mailman/listinfo/behave
>>>       
>>     
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>
>
>   