Re: [BEHAVE] address-format secure configuration

[Brian E Carpenter <[e-mail]>]

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