Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04

["Bhatia, Manav (Manav)" <[e-mail]>]

I am aware of some implementations that look at the IP header to determine the source. I think it's a very good catch and we could append the following before the original text:

"In some OSPF implementations neighbors on broadcast .. " 

Does this sound acceptable?

Cheers, Manav

> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]] 
> Sent: Friday, May 28, 2010 7.03 PM
> To: Sam Hartman
> Cc: Bhatia, Manav (Manav); [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [secdir] Review of 
> draft-ietf-opsec-routing-protocols-crypto-issues-04
> 
> Hi.  I was attempting to reconcile this draft against
> draft-ietf-rpsec-ospf-vuln, an old draft on OSPF vulnerabilities.
> Section 4.2.2.4 of the rpsec draft disagrees with the last 
> paragraph of
> section 2 of the opsec draft.  That paragraph talks about the 
> attack in
> which the IP address of a hello packet is replayed in order to cause a
> node to think that a connection is not bidirectional.  The rpsec draft
> argues that attack doesn't work because the router ID, not the source
> address is used.  The rpsec draft also kind of implies this may depend
> on implementations.
> 
> I'm not sure which draft is right.  However, since there has been
> argument about whether this attack is possible,the opsec 
> draft needs to
> either acknowledge or resolve this issue.  (Obviously, I'd prefer that
> you resolve the issue: it makes our lives easier in karp, but if you
> don't have time, I understand just describing it.)
> 
> In particular, I believe the opsec draft should cite as an informative
> reference section 4.2.4 of draft-ietf-rpsec-ospf-vuln         
>          9
> aand do one of the following:
> 
> * Agree with the conclusions
> 
> * State it is an implementation matter whether a particular
>   implementation is vulnerable
> 
> * Explain why the rpsec draft is wrong
> 
> * Note that the issue is open
> 
> Thanks,
> 
> --Sam
>