Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt

On 21/09/2012 12:11, RJ Atkinson wrote:
> On 20  Sep 2012, at 15:56 , Di Ma wrote:
>> Since the IPSec is address-oriented...
> 
> We continue to disagree about this.

Put it this way. The community needs to change its bad habit of using IPSec
in an address-oriented way, and renumbering is one of the main reasons
for that. So it is 6renum's job to strongly recommend the change.

It remains true, of course, that even if an SA survives renumbering,
the transport session running over that SA will also have to be renumbered,
but that's a separate problem.

   Brian

> 
>> ...and the DHCP server is responsible for IP address configuration,
>> we might as well integrate IPSec SA parameters configuration into
>> IP address assignment by extending DHCP where the IP address
>> configuration node (DHCP server) plays like an “administrator”
>> using DHCP to configure IPSec SA parameters in a host, after it,
>> in deputy of the host, has negotiated with a CPN server the
>> very host wants to establish IPSec with.  
> 
> This seems very unwise for any IETF standards work,
> from multiple perspectives.  A quick subset of examples,
> each by itself sufficient to illustrate why this would
> be unwise, follow:
> 
> 
> * A very basic one is that one would not want to standardise 
>   the trust model issues that such an approach would create.
> 
>   EXAMPLE:
>   While I might trust the DHCP server at the coffee shop
>   for the limited function of assigning an IP address and
>   conveying minimally essential IP-layer information to my
>   laptop, I definitely DO NOT trust the coffee shop network
>   or its infrastructure components (e.g. DHCP server).  So
>   when I would begin work, I would always want to directly
>   secure the communications channel between my laptop and
>   my workplace -- without ANY intermediaries.
> 
> 
> * Related to that, user security and privacy would be 
>   compromised by such centralisation and the delegation 
>   implied by "in deputy of the host".  
> 
>   EXAMPLE:
>   Basically, the proposal would be to standardise use of any
>   DHCP server as an attacker for an automated "man in the middle" 
>   attack.  I see zero chance of the IETF Security Area
>   approving this.
> 
> 
> * DHCP is not suitable for key management, while the above
>   proposes using DHCP to manage keys (IPsec SAs).
> 
> 
> Given these issues, and previous notes in this thread explaining
> how IPsec-related renumbering works today, it is not obvious that 
> the contents of your note are appropriate for this gap analysis 
> document.  
> 
> Yours,
> 
> Ran
> 
> 
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum
> 