Re: [secdir] Secdir review of draft-ietf-mboned-64-multicast-address-format-01

[<[e-mail]>]

Dear Matt,

Thank you for the review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Matt Lepinski [mailto:[e-mail]] 
>Envoyé : mardi 5 juin 2012 05:50
>À : [e-mail]; [e-mail]; 
>[e-mail]
>Objet : Secdir review of 
>draft-ietf-mboned-64-multicast-address-format-01
>
>I have reviewed this document as part of the security 
>directorate's ongoing effort to review all IETF documents 
>being processed by the IESG. These comments were written 
>primarily for the benefit of the security area directors. 
>Document editors and WG chairs should treat these comments 
>just like any other last call comments.
>
>This document specifies an embedding (for use by IPv4 to IPv6 
>translation devices) as an IPv4 multicast address within an 
>IPv6 address. (This is a companion document to RFC 6052, which 
>specifies an embedding for IPv4 unicast addresses.)
>
>The Security Considerations section claims that the relevant 
>security considerations are identical to those in RFC 6052. 
>(That is, the security considerations for translating IPv4 
>multicast addresses are the same as those for translating 
>unicast addresses.) I believe this is essentially true.
>
>However, the first security consideration discussed in RFC 
>6052 is source address spoofing. Although quite relevant for 
>unicast address translation, source address spoofing does not 
>seem (to me) to be an issue for multicast addresses 
>translation because multicast addresses are typically not used 
>as source addresses for IP datagrams. 

Med: address spoofing may also be harmful in multicast context (e.g., send illegitimate PIM register messages).

In situations such as 
>this where the authors wish to incorporate security 
>considerations by reference, I think it is helpful to the 
>reader to add a couple sentences explaining which 
>considerations in the referenced document (i.e., RFC 6052) are 
>relevant to the current draft.

Med: I personally think all items discussed in RFC6052 are still valid for this draft. Do you think there is a need to modify the text? 

>
>Minor editorial note:
>It would be helpful if you define the acronyms ASM and SSM in 
>the terminology section. (As someone who doesn't frequently 
>think about multicast, it wasn't immediately obvious to what 
>these two acronyms referred.)

Med: I fixed it in -02. See the diff available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-02.txt