Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt

[Greg Mirsky <[e-mail]>]

Dear Carlos,
thank you for the suggestions. Attached are the working version and the
diff. My notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, May 5, 2020 at 6:11 PM Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Hi, Greg,
>
> Thanks for the quick reply, please see inline.
>
> —
> Carlos Pignataro, [e-mail]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> 2020/05/05 午後8:10、Greg Mirsky <[e-mail]>のメール:
>
> Dear Carlos,
> I'll do top-posting to highlight the remaining points of discussion.
> Please correct me if my understanding is not correct:
>
>    - the reference to Section 5 RFC 5881 in the following sentence:
>
>    Validation of TTL or Hop Limit of the inner IP packet is performed as
> described in Section 5 [RFC5881].
>
>
>
> “Validation of TTL / Hop Limit of the inner IP packet, as long as the
> related considerations for BFD control packet demultiplexing and
> authentication, is performed as described in Section 5 [RFC5881].”
>
GIM>> Thank you, accepted.

>
>
> I expect that a reader of BFD over VXLAN document is able to find the
> relevant information in Section 5 of RFC 5881. Do you think that the
> reference to Section 5 RFC 5881 might be confusing to the reader? Would you
> suggest to use another reference without replicating the text from RFC 5881
> in this document?
>
>
>    - Security Considerations section
>
> You've suggested:
> Currently the security considerations does not say “security
> considerations of 5881 apply here”, nor does it say “the ttl/hl protection
> isn’t useful in foobar “
>
> I think it should say both.
>
> This draft discusses the use of BFD over VXLAN. Do you mean that 'foobar'
> is BFD over VXLAN? Since security considerations in RFC 7348 are applicable
> in this draft, I don't think that GTSM is not useful in the case of BFD
> over VXLAN. Or I misinterpreted 'foobar'? Could you please clarify it?
>
>  Would the following update is acceptable:
> OLD TEXT:
>    Other than requiring control of the number of BFD sessions between
>    the same pair of VTEPs, this specification does not raise any
>    additional security issues beyond those discussed in [RFC5880],
>    [RFC5881], and [RFC7348].
> NEW TEXT:
>    Other than requiring control of the number of BFD sessions between
>    the same pair of VTEPs, this specification does not raise any
>    additional security issues beyond those discussed in [RFC5880],
>    [RFC5881], and [RFC7348] that apply to this document.
>
>
> I am sorry, as I read this I do not fully understand the first part. What
> is to “require _control_ of the number of sessions”?
>
> I would split that long sentence into two.
>
GIM>> I agree, the sentence is too convoluted. Would removing it altogether
and adding the following at the top of the section make it clearer:
   Security issues discussed in [RFC5880], [RFC5881], and [RFC7348]
   apply to this document.

>
>
>
>    - Acknowledgments
>
> Thank you. I'll thoroughly look through all the relevant discussion
> threads in the mail archive.
>
>
> Sounds good.
>
> Thanks,
>
> Carlos.
>
>
>
> Regards,
> Greg
>
>
> On Mon, May 4, 2020 at 7:52 PM Carlos Pignataro (cpignata) <
> [e-mail]> wrote:
>
>> Dear Greg,
>>
>> As I said, I did *not* review the updated version (or the changes)
>> thoroughly (or superficially for that matter)
>>
>> Please do not count this as a review of the new revision, and instead
>> consider the context that I laid for my reply.
>>
>> I only checked the changes for one comment I had made.
>>
>> Please see inline.
>>
>> Thumb typed by Carlos Pignataro.
>> Excuze typofraphicak errows
>>
>> 2020/05/04 午後10:15、Greg Mirsky <[e-mail]>のメール:
>>
>> Dear Carlos,
>> thank you for your thorough review of the updated version,
>>
>>
>> I didn’t. This is what I had said:
>>
>> I have not checked the diff and the new text regarding the Eth MAC and
>> mgmt VNI.
>>
>> Assuming that was clear...
>>
>> helpful and
>> constructive suggestions.
>>
>>
>> Thanks. That was the intent, but only for the TTL/HL change.
>>
>> Please find my answers in-line tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata)
>> <[e-mail]> wrote:
>>
>>
>> Dear Greg,
>>
>>
>> I have not checked the diff and the new text regarding the Eth MAC and
>> mgmt VNI.
>>
>>
>> However, these diffs also include a change that you did not mention: TTL
>> / Hop Limit handling, which is one of the comments I had made.
>>
>>
>> In that context, thank you very much! since this update partially
>> (although largely) addresses my comment.
>>
>>
>> Still missing:
>>
>>
>>         TTL or Hop Limit: MUST be set to 255 in accordance with the
>>
>>         Generalized TTL Security Mechanism [RFC5881].
>>
>>
>> CMP: this is an incorrect citation. The GTSM is RFC 5082, not RFC 5881. I
>> recommend adding a Reference to RFC 5082 (as I’d suggested before).
>>
>> GIM>> Agreed, will change the reference to RFC 5082
>>
>>
>> Thanks.
>>
>>
>>   Validation of TTL or Hop Limit of the inner IP packet is performed as
>>
>>   described in Section 5 [RFC5881].
>>
>>
>> CMP: This is an oversimplification. S5 of RFC 5881 explains not only how
>> to validate TTL/HL, but also about demultiplexing tulles in presence of
>> auth and various header fields.
>>
>> GIM>> I've compared Section 3 of RFC 5082 and Section 5 of RFC 5881
>> and still believe that for this document the reference to Section 5 of
>> RFC 5881 is more helpful to a reader and an implementor.
>>
>>
>> Yes, I agree with this. I did not say “change this reference to 5082” —
>> that was the previous comment on a different passage.
>>
>> Section 5
>> provides an explicit specification on handling TTL/HC != 255 by a
>> receiving BFD system. I think that it is important to reference
>> Section 5, as the handling of TTL/HC != 255 is different depending on
>> whether the BFD session is in unauthenticated or authenticated mode.
>> Would you agree?
>>
>>
>> Yes, but that’s orthogonal to my comment.
>>
>> My point is that the relevant text from section 5 does more than simply “
>> Validation of TTL or Hop Limit ”
>>
>>
>> 9.  Security Considerations
>>
>>
>> CMP: A discussion on the positive impact of using GTSM would help here.
>>
>> GIM>> The Security Consideration section in RFC 5881 provides the
>> excellent text on the benefit of using GTSM in both, unauthenticated
>> and authenticated, modes. the last para in the Security Consideration
>> section of this document mentioned the discussion in several RFCs,
>> including in RFC 5881. Do you think that an additional text about the
>> use of GTSM in single-hop BFD should be added in this document?
>>
>>
>> Yes, that’s why I made the comment!
>>
>> Currently the security considerations does not say “security
>> considerations of 5881 apply here”, nor does it say “the ttl/hl protection
>> isn’t useful in foobar “
>>
>> I think it should say both.
>>
>> Could
>> you suggest some text?
>>
>>
>> 11.  Acknowledgments
>>
>>
>> CMP: Both professional courtesy as well as proper record and provenance
>> tracking suggest keeping an updated Acknowledgements section.
>>
>> GIM>> My apologies, I've updated the working version accordingly.
>>
>>
>> To be clear, I’m not talking about me but about others who invested more
>> time helping with this doc, like Joel and others. It would be useful to go
>> through the list archive (to also ensure all comments are captured, since
>> they were made SO long ago)
>>
>> Best,
>>
>> Carlos.
>>
>>
>> Best,
>>
>>
>> —
>>
>> Carlos Pignataro, [e-mail]
>>
>>
>> “Sometimes I use big words that I do not fully understand, to make myself
>> sound more photosynthesis."
>>
>>
>> 2020/05/04 午後6:58、Greg Mirsky <[e-mail]>のメール:
>>
>>
>> Dear All,
>>
>> my apologies for holding off this upload. The update is to address a
>>
>> set of comments related to the use of destination Ethernet MAC in the
>>
>> inner Ethernet frame that encapsulates a BFD control message. A new
>>
>> section on the use of the Management VNI has been added and the
>>
>> document now considers only the case of using the Management VNI to
>>
>> transmitted receive BFD control messages.
>>
>> Always welcome your questions and comments.
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>> ---------- Forwarded message ---------
>>
>> From: <[e-mail]>
>>
>> Date: Mon, May 4, 2020 at 3:50 PM
>>
>> Subject: New Version Notification for draft-ietf-bfd-vxlan-11.txt
>>
>> To: Mallik Mudigonda <[e-mail]>, Sudarsan Paragiri
>>
>> <[e-mail]>, Greg Mirsky <[e-mail]>, Santosh
>>
>> Pallagatti <[e-mail]>, Vengada Prasad Govindan
>>
>> <[e-mail]>
>>
>>
>>
>>
>> A new version of I-D, draft-ietf-bfd-vxlan-11.txt
>>
>> has been successfully submitted by Greg Mirsky and posted to the
>>
>> IETF repository.
>>
>>
>> Name:           draft-ietf-bfd-vxlan
>>
>> Revision:       11
>>
>> Title:          BFD for VXLAN
>>
>> Document date:  2020-05-04
>>
>> Group:          bfd
>>
>> Pages:          11
>>
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-11.txt
>>
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>>
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-bfd-vxlan-11
>>
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
>>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-11
>>
>>
>> Abstract:
>>
>>  This document describes the use of the Bidirectional Forwarding
>>
>>  Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>>
>>  Area Network (VXLAN) tunnels used to form an overlay network.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>>
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>