Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

Manav/Acee -

Thanx for the replies. Given that the IETF community at large does not favor use of UTC (as demonstrated by how various protocols have addressed the replay attack issue) AND the fact that at least one of the authors also doesn't favor it there seems little justification for keeping this text in the document. The responses from Manav and Acee advance the case for changing the text - though I am stopping short of saying this is a MUST - largely because as a practical matter the BFD WG seems to have been smart enough (in part because of you Manav) to ignore this recommendation.

   Les


From: Acee Lindem (acee)
Sent: Thursday, July 31, 2014 6:47 AM
To: manav bhatia; Les Ginsberg (ginsberg)
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

Hi Manav,
I agree with Les though I may have logged this as a major issue. What if the next-hop used to reach your NTP server is validated using authenticated multi-hop BFD?  Also, It is seems a bit superficial to recommend usage of UTC for the high order 32 bits of the sequence number without dealing without mentioning the 2038 wrap for the UNIX time.
Thanks,
Acee

From: Manav Bhatia <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 31, 2014 at 8:22 AM
To: "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

Hi Les,

Thanks for the comments.



Minor Issues: I am a little surprised that the use of UTC is emphasized as a means of preventing replay attacks. While this is certainly a viable solution what has been more commonly used by a number of other protocols is reserving a portion of the sequence number for a boot count. In fact this is the way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt  has chosen. Yet this document chooses to emphasize UTC encoding.


I am the author of the standards that started using the boot count initially as a way to preserve the crypto sequence count. I am not a big fan of UTC and this was suggested as a plausible mechanism that did not appear to be outright loony (especially when you have increased the seq space to 64 bits). Let me put it this way - I wouldnt be baying for blood if the directorate believes that this is a retrogressive step and we need to snip out that section.


Nits:



1)The affiliation for one of the authors (Manav) is inconsistent in the header vs the authors addresses section.

Will fix this. For the record, i now work for Ionos Networks.




2)In the Introduction the last sentence of the second paragraph reads:



"Moving the routing protocols to a stronger

   algorithm while using weaker algorithm for BFD would require the

   attacker to bring down BFD in order to bring down the routing

   protocol. "

I think what is meant is that if the BFD authentication algorithm is weaker than that used by the routing protocols it is more likely to be the target of an attack. The phrase "require the attacker..." seems inappropriate.

Gotcha. Will fix this.




3)Section 3 last sentence of the penultimate paragraph:



s/reply/replay

.. and this.




4)Section 6 Second paragraph second sentence



s/notion/the notion

.. and this as well.

Thanks,

Manav



Thanx.



   Les