Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 May 2008 15:13:47 -0700 (PDT)

Please see inline.

Regards,

Behcet

----- Original Message ----
From: marcelo bagnulo braun <[email-masked]>
To: Arnaud Ebalard <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Friday, May 30, 2008 4:45:08 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Arnaud,

thanks for the feedback

Arnaud Ebalard escribió:
> Hi,
>
> marcelo bagnulo braun <[email-masked]> writes:
>
>  
>> We would like to ask the WG what is their opinion about accepting
>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD
>> deliverable included in our charter.
>>
>> Please provide comments so we cna make some progress on this long
>> overdue deliverable
>>    
>
> The document is short and easy to read (good point). On one side, I
> think that DHCPv6 makes some sense for Nemo PD for devices with some
> capabilities. On the other side, I wonder if it is not overkill
> (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?)
> that will serve a single subnet with IPv6 stateless @ autoconf 
>
> In practice (as a HA and MR administrator), I'd like to be able to
> simply configure the prefixes for my MR in the HA configuration section
> for this MR and that those prefixes be sent to the MR during the
> initial binding if it ask for prefix(es). In a sense considering the
> an initial static configuration of a MR, switching to PD would mean:
>
>   - changing a knob in the MR config to switch to prefix delegation
>   - giving the prefix in the HA config, indicating PD for that MR
>
> i.e. no need for IDs, specific keys for auth, or additional relay and
> associated IPsec credentials config.

I think this is a good point, we should not hurry up a solution just because it was long overdue.
I have the same concern. Instead of MR, HA could be a better place for DHCP PD. 
http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt explains this and it is a much simpler document.

I am not sure what you mean hre. Are you suggesting any additional 
changes in the document? Or are you proposing using a different 
mechanism other than dhcp for this?

If it is the first one, please comment how to do this.

If it is the second one, there is consensus in the WG (decided in the 
last meeting and confirmed in the ml) that we are using dhcp for this, 
so pleas do not go into this disucssion again

> I also have some comments on the "Security Considerations" section of
> the document. Don't hesitate to tell me if I missed sth or if it is out
> of scope.
>
> IMHO, this is a bit simplistic to delegate the security of NEMO PD to
> the Security Considerations sections of DHCPv6 and DHCPv6 PD documents.
> There are good chances that the environments where MR will operate may
> be a bit more hostile than those where more common routers are expected
> to operate (in operators or corporate networks). 
>
> Some initial thoughts:
>
> - What are the hypothesis behind 3315 and 3633 design decisions that do
>   not hold anymore in MIPv6 environments (if any)?
> - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"?
> - how do the security mechanisms of both protocols interact?
> - In the simple mode (no relay), how will the use of multicast interact
>   with IPsec protection of traffic if it is in place?
> - HMAC-MD5-based authentication method is the only one defined in
>   3315. Is it sufficient?
> - What is the impact of the assignment of new prefixes in a dynamic
>   fashion w.r.t. the SPD and SADB or IKE daemons? How should that be
>   handled.
> - ...
>
>  
This should be discussed, since the security was one of the points that 
needed more work and that the authors tried to address in thei document

Regards, marcelo

> Regards,
> a+

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext