Re: [BEHAVE] address-format secure configuration

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

I agree, it doesn't belong here, but it is important. Some of the issues
and mechanisms are covered in draft-carpenter-renum-needs-work-05.txt, which
is now in the RFC Editor queue (having passed the IESG as a direct submission
to one of the Ops ADs). The topic probably belongs in v6ops IMHO.

Regards
   Brian Carpenter

On 2010-04-01 10:16, Dave Thaler wrote:
> 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
>