Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-transition-to-ospfv3-10: (with COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Stephen, 

On 6/29/16, 9:06 AM, "OSPF on behalf of Stephen Farrell"
<[e-mail] on behalf of [e-mail]> wrote:

>Stephen Farrell has entered the following ballot position for
>draft-ietf-ospf-transition-to-ospfv3-10: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>
>section 4: Just checking that I've gotten this right. Is the
>following correct?
>
>If RFC7166 is being used then there is never a need to modify
>packets in a way that would break the authentication. In other
>words, am I correct that this draft doesn't envisage any middlebox
>changing an OSPF packet in between the source (of authentication)
>and destination(s)?

I think it would be undesirable for a middlebox to modify OSPF packets
under any circumstances. I see no requirement for this and, if there were,
transport of OSPFv3 over IPv4 doesn’t expand or contract the types of
modifications that a middle box could perform without breaking RFC 7166.
For both IPv4 and IPv6 transport, the source address is included in the
authentication digest calculation and cannot be modified.

Thanks,
Acee 


> 
>
>If that is correct, then we're good.
>
>If that is not correct, then I think more needs to be said in
>section 4, as it is not at all clear to me how a source could emit a
>packet that a middlebox could modify, without having to share the
>symmetric secret used for RFC7166 authentication with that
>middlebox, which would be fairly clearly undesirable.



>
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf