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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 31 Jul 2014 06:03:00 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-karp-bfd-analysis-04

Reviewer: Les Ginsberg

Review Date: July 30, 2014

IETF LC End Date: August 12, 2014

Intended Status: Informational

Summary:  This document is basically ready for publication, but has minor editorial issues that should be corrected prior to publication. I also have a minor concern which the authors may want to address.

Major Issues: None

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.

Nits:

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

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.

3)Section 3 last sentence of the penultimate paragraph:

s/reply/replay

4)Section 6 Second paragraph second sentence

s/notion/the notion

Thanx.

   Les

---

From: manav bhatia <[email-masked]>
Date: Thu, 31 Jul 2014 17:52:16 +0530

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.

> header vs the authors addresses section.

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

>  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:

.. and this.

> 4)Section 6 Second paragraph second sentence

.. and this as well.

Thanks,

Manav

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 31 Jul 2014 13:47:20 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 31, 2014 at 8:22 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

Hi Les,

Thanks for the comments.

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:

   protocol. "

Gotcha. Will fix this.

s/reply/replay

.. and this.

s/notion/the notion

.. and this as well.

Thanks,

Manav

Thanx.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 31 Jul 2014 14:37:04 +0000

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: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

Hi Manav,

Hi Les,

Thanks for the comments.

Nits:

   protocol. "

Gotcha. Will fix this.

s/reply/replay

.. and this.

s/notion/the notion

.. and this as well.

Thanks,

Manav

Thanx.

   Les