Subject: Re: [Rift] On the use of the origination_time

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Sep 2018 15:49:14 +0000

Hello Tony :

Another usage when present would be for the corner cases we discussed:
4) Sort TIEs for a same prefix from same source received as both positive and negative. If they are sent at different times, we can compare those times, and since this is the clock of the sender, they do not need to be synchronized

For the rest please see below:

From: Antoni Przygienda <[email-masked]>
Sent: mardi 25 septembre 2018 17:13
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: On the use of the origination_time

Taking it to wider list given possible LSR interest in that … Discussion is centered around the schema element

/** Header of a TIE.

   @note: TIEID space is a total order achieved by comparing the elements

              in sequence defined and comparing each value as an

              unsigned integer of according length. `origination_time` is

              disregarded for comparison purposes.

*/

struct TIEHeader {

    2: required TIEID                             tieid;

    3: required common.SeqNrType                  seq_nr;

    /** remaining lifetime that expires down to 0 just like in ISIS.

        TIEs with lifetimes differing by less than 2 seconds MUST

        be considered EQUAL. */

    4: required common.LifeTimeInSecType          remaining_lifetime;

    /** optional absolute timestamp of when the TIE

        was generated. This can be used on fabrics with

        some kind of synchronized clock to prevent

        lifetime modification attacks. */

   10: optional common.IEEE802_1ASTimeStampType   origination_time;

}

where we decided to add an optional absolute timestamp to deal with things like RFC7987 and possibly other benefits

asnwers to your mail inline

<[email-masked]<mailto:[email-masked]>> spake:

    Dear all:

    I remember the discussion at the hackathon - but not strictly all the details - that lead to the new field origination_time.

    I think the main question was an in-flight attack against the remaining_lifetime, but the details of what we wanted to do at the time are now blurred.

    Now let's look at it and what it can serve:

1)      It is a nonce, making the TIE unique if we decide to protect it at origin, and provides anti-replay.

+1

2)      It could be used to validate the remaining_lifetime indicated in the spec. We could have a well-known max_lifetime in which case now + remaining_lifetime <= origination_time + max_lifetime + fudge, or better, indicate the original_lifetime in the TIE as well, in which case we can check that || (now + remaining_lifetime) - (origination_time + original_lifetime) || <= fudge

I think about this but in opposite sense. A network could be configured with well-known _minimum_ lifetime to protect against people attacking by lowering lifetime to force expiry (the spec won’t mandate that, we found over years that min & max hardcoded stuff on lifetimes in routing protocols is always stymied by deployment realities over years). Also, RFC7987 could be easily taken as is and offers a fairly good practical approach

[PT>] Agreed. Adding the original_lifetime is only useful if there is a minimal time sync between nodes but then it provides a defense against all attacks, increment or decrement.

    3) It could be part of the TIE sequencing, using the same rules as for fast mobility, for now the spec says use sequence only. Reason for that is avoid the traditional sequence issues of wrapping sequence and reboot (lollipop) for a long life RIFT.

As you know I am opposed against it:

1)      We cannot assume there will be a clock sync on the fabric of any quality.

2)      Why would anyone issue same seqnr# at different times, that’s basically an implementation bug

3)      Comparison of those things is not cheap @ high rate, how fast you can compare/reflood TIEs is one of the important metrics in a good implementation.

4)      Sequence numbers are protected (security envelope) so they no one can attack by bumping them up arbitrarily

5)      2**32 is about 130 years worth if you re-issue TIE every single second

6)      If we’re really concerned about that rollover is well understood. It was written down in https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00 , I’m not sure that expired or is still around.

[PT>] One case was reboot. Where do we restart. A seq == 0 with a more recent time would be a clear indication that everything older is deprecated. The time would only be checked for low sequence numbers, and lead to a very different code path.

    If out of those, we decide that only 2) is useful, then we'd probably prefer to indicate the end of the lifetime as an absolute date (origination_time + original_lifetime)  as opposed to the emission time.

    IMO, no, but this here may trigger further discussion on points we don’t see …

[PT>]

I agree just raising the question to be sure.

[PT>] all the best,

Pascal

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 25 Sep 2018 16:12:08 +0000

That is a decent idea and we could put a “can” into the draft since again, we cannot assume synchronized clock as precondition on the fabric …

--- tony

Thus spake <[email-masked]<mailto:[email-masked]>>:

Hello Tony :

/** Header of a TIE.

*/

struct TIEHeader {

    2: required TIEID                             tieid;

        be considered EQUAL. */

}

    Dear all:

+1

6)       If we’re really concerned about that rollover is well understood. It was written down in https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmanjuldtv-2Dospf-2Dsequence-2Dnumber-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=a2OSyvzmfvsJau1GoEboBGUiM5vPcwBfLKeW_89sVxA&s=dWHXOJ7t6qhQavP2oY3QCsjwzSYf3gYoqSaiI5lrbhE&e=> , I’m not sure that expired or is still around.

[PT>]

[PT>] all the best,

Pascal

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 25 Sep 2018 15:12:42 +0000

/** Header of a TIE.

*/

struct TIEHeader {

    2: required TIEID                             tieid;

        be considered EQUAL. */

}

<[email-masked]> spake:

    Dear all:

+1

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 25 Sep 2018 14:50:27 -0700

Dear All,
if reading the timestamp was envisioned in the control plane, then you may
find that NTPv4 format is more common (yes, it's just an API away to
convert from NTP to PTP). In the data plane, PTP as native format may be
more common. Thus, may I suggest to explicitly indicate the type of the
format and, optionally, the length occupied by the timestamp, e.g., 32, 64,
or 128 bits long.

Regards,
Greg

On Tue, Sep 25, 2018 at 9:12 AM Antoni Przygienda <[email-masked]> wrote:

> That is a decent idea and we could put a “can” into the draft since again,
> we cannot assume synchronized clock as precondition on the fabric …
>
>
>
> --- tony
>
>
>
>
>
> Thus spake <[email-masked]>:
>
>
>
> Hello Tony :
>
>
>
> 4) Sort TIEs for a same prefix from same source received as both positive
> and negative. If they are sent at different times, we can compare those
> times, and since this is the clock of the sender, they do not need to be
> synchronized
>
>
>
> *From:* Antoni Przygienda <[email-masked]>
> *Sent:* mardi 25 septembre 2018 17:13
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: On the use of the origination_time
>
>
>
>    *10: optional common.IEEE802_1ASTimeStampType   origination_time;*
>
> }
>
>
>
>     I remember the discussion at the hackathon - but not strictly all the
> details - that lead to the new field origination_time.
>
>     I think the main question was an in-flight attack against the
> remaining_lifetime, but the details of what we wanted to do at the time are
> now blurred.
>
>
>
> 2)       It could be used to validate the remaining_lifetime indicated in
> the spec. We could have a well-known max_lifetime in which case now +
> remaining_lifetime <= origination_time + max_lifetime + fudge, or better,
> indicate the original_lifetime in the TIE as well, in which case we can
> check that || (now + remaining_lifetime) - (origination_time +
> original_lifetime) || <= fudge
>
>
>
> I think about this but in opposite sense. A network could be configured
> with well-known _*minimum*_ lifetime to protect against people attacking
> by lowering lifetime to force expiry (the spec won’t mandate that, we found
> over years that min & max hardcoded stuff on lifetimes in routing protocols
> is always stymied by deployment realities over years). Also, RFC7987 could
> be easily taken as is and offers a fairly good practical approach
>
> *[PT>] Agreed. Adding the original_lifetime is only useful if there is a
> minimal time sync between nodes but then it provides a defense against all
> attacks, increment or decrement. *
>
>
>
>     3) It could be part of the TIE sequencing, using the same rules as for
> fast mobility, for now the spec says use sequence only. Reason for that is
> avoid the traditional sequence issues of wrapping sequence and reboot
> (lollipop) for a long life RIFT.
>
>
>
> 3)       Comparison of those things is not cheap @ high rate, how fast
> you can compare/reflood TIEs is one of the important metrics in a good
> implementation.
>
> 4)       Sequence numbers are protected (security envelope) so they no
> one can attack by bumping them up arbitrarily
>
> 6)       If we’re really concerned about that rollover is well
> understood. It was written down in
> https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmanjuldtv-2Dospf-2Dsequence-2Dnumber-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=a2OSyvzmfvsJau1GoEboBGUiM5vPcwBfLKeW_89sVxA&s=dWHXOJ7t6qhQavP2oY3QCsjwzSYf3gYoqSaiI5lrbhE&e=>
> , I’m not sure that expired or is still around.
>
>
>
> *[PT>] One case was reboot. Where do we restart. A seq == 0 with a more
> recent time would be a clear indication that everything older is
> deprecated. The time would only be checked for low sequence numbers, and
> lead to a very different code path.*
>
>
>
>     If out of those, we decide that only 2) is useful, then we'd probably
> prefer to indicate the end of the lifetime as an absolute date
> (origination_time + original_lifetime)  as opposed to the emission time.
>
>
>
> *[PT>] *
> *I agree just raising the question to be sure.*
>
>
>
> *[PT>] all the best,*
>
>
>
> *Pascal*
>
>
> _______________________________________________
> RIFT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rift
>