Re: [Lsvr] AD Review of draft-ietf-lsvr-bgp-spf-19

[Alvaro Retana <[e-mail]>]

Hi!

For some reason I woke up thinking about semantic validation...in the
middle of the night. :-(


Semantic validation is something that has always been missing from BGP-LS
-- that's what the authors/WG wanted.  As you can see from the multiple
"IGP to BGP-LS" documents, it is a discussion I've had many times with
Ketan (as lead author) that eventually concluded in being very specific
about the BGP-LS Consumer role in rfc7752bis to clearly leave only
syntactic validation in scope.

I think it is important for BGP-SPF to define semantic validation because
it will use the information to calculate routes.  The contents of the TLVs
cannot be incorrect, out of range, inconsistent, etc.


Short of defining the expected content of every TLV, I wonder if we can do
it through reference.  Many of the TLVs in rfc7752bis are directly derived
from OSPF/IS-IS LSA/LSPs -- can the BGP SPF spec say that the contents of
the TLVs MUST be compliant with the IGP specifications?  For example...

(1) One of the first TLVs listed in rfc7752bis is TLV 258 (Link
Local/Remote
    Identifiers), which is directly mapped to IS-IS's TLV/Sub-TLV 22/5 from
    §1.1/rfc5307 (Link Local/Remote Identifiers):

   =====
   A Link Local Interface Identifier is a sub-TLV of the extended IS
   reachability TLV.  The type of this sub-TLV is 4, and the length is 8
   octets.  The value field of this sub-TLV contains 4 octets of Link
   Local Identifier followed by 4 octets of Link Remote Identifier (see
   Section 2.1, "Support for Unnumbered Links", of [GMPLS-ROUTING]).  If
   the Link Remote Identifier is unknown, it is set to 0.

   The following illustrates encoding of the Value field of the Link
   Local/Remote Identifiers sub-TLV.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Link Local Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Link Remote Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than
   once within the extended IS reachability TLV.  If the Link
   Local/Remote Identifiers sub-TLV occurs more than once within the
   extended IS reachability TLV, the receiver SHOULD ignore all these
   sub-TLVs.
   =====

    BGP SPF/§5.2.2: "For unnumbered links, the link local/remote
identifiers
    (TLV 258) will be used."

    Even though this looks straightforward: the GMPLS-ROUTING reference
    basically says that each side makes up a number.  The problem is that
§1.5/
    rfc5307 says this:

   =====
   Link Identifiers are exchanged in the Extended Local Circuit ID field
   of the "Point-to-Point Three-Way Adjacency" IS-IS Option type
[ISIS-3way].
   =====

    IS-IS uses Hellos to figure out the IDs.  But there is no 3-way
handshake,
    or Hellos in BGP SPF.  How are these values learned?

    §4.2/§4.3 (but not §4.1!?) talk about "connection discovery".  Some
text
    can be added to hint at what type of information is expected to be
    discovered, and even use l3dl as an example of how to get it.


    Ok -- this first example wasn't great, and it discovered another issue.



(2) Let's try TLV 259 (IPv4 interface address), which maps to §3.2/rfc5305:

   =====
   This sub-TLV contains a 4-octet IPv4 address for the interface
   described by the (main) TLV.  This sub-TLV can occur multiple times.
   =====

    This one does look straightforward. :-)   Even though rfc5305 doesn't
say
    what to do if the contents are not an IPv4 address (for example
0.0.0.1),
    we can safely assume that it should be considered malformed.

    BGP SPF/§5.2.2: "For IPv4 links, the link's local IPv4 (TLV 259) and
remote
    IPv4 (TLV 260) addresses will be used."

    The remote IP address (TLV 260) has a similar definition in rfc5305 and
is
    also something that seems to fall under "connection discovery".

    BGP SPF already requires that the addresses belong to the same subnet,
    which rfc5305 said nothing about.  Good!



(3) Let's look at TLV 516 (BGP Router-ID), which is specified in
§4.1/rfc9086.
    BTW, please add a normative reference to it.

   =====
   BGP Router Identifier (BGP Router-ID):

    Type: 516

    Length: 4 octets
    Value: 4-octet unsigned non-zero integer representing the
    BGP Identifier as defined in [RFC6286]
   =====

    This one also looks straightforward and answers my question below. :-)
 If
    the value is 0 then it is not in line with rfc9086/rfc6286 and it
should be
    considered malformed.  Right?

    Given that the contents of this TLV (and TLV 512 - more on this below)
    should be the same as the BGP ID in the BGP OPEN message, should there
be
    any check to make sure that NLRIs from connected nodes have the same
    information in their descriptors when running SPF?



(4) Back to TLV 512 (Autonomous System).  At first glance it seems that we
can
    assume that this is the ASN number, the same as the OPEN message,
etc..but
    this is the definition from §5.2.1.4/rfc7752bis:

   =====
   Autonomous System:  Opaque value (32-bit AS Number).  This is an
   optional TLV.  The value SHOULD be set to the AS Number associated
   with the BGP process originating the link-state information.  An
   implementation MAY provide a configuration option on the BGP-LS
   Producer to use a different value; e.g., to avoid collisions when
   using private AS numbers.
   =====

    The text doesn't require it to be the same as what is on the BGP OPEN.
It
    even let's any ASN be used. :-(  I don't remember what the
justification
    was, but I'll send a message to Ketan about it.

    If BGP SPF wants TLV 512 to contain the ASN from the OPEN, and check
(?)
    while running SPF, then it has to be specified because it is different
than
    rfc7752bis.




All this is to say that I think we can address semantic validation by
adding some text like this (suggestions):

   3. BGP Link-State (BGP-LS) Relationship

   Semantic validation of the TLVs defined in rfc7752bis MUST be
   performed against the specifications in the underlying OSPF or
   IS-IS specifications: rfc5305, rfc5307, ...  If the semantic
   validation fails, then the TLV MUST be considered malformed
   (Section 7.1).

   [There should be normative references added.]


   7.1. Processing of BGP-LS-SPF TLVs

   A TLV that is determined to be malformed MUST...  [There might
   be different actions to be taken, but treat-as-withdraw sounds
   relatively safe to me.]


   [Any exceptions or special processing needs to be specified.  For
example.]

   5.2. Extensions to BGP-LS

   The format of TLV 512 is defined in rfc7752bis, when used in a
   BGP-LS-SPF NLRI the content MUST be as follows:

     Autonomous System:  Opaque value (32-bit AS Number).  The
     value MUST be set to the AS Number associated with the BGP
     process originating the link-state information.


   [Generalize the text about "connection discovery" and provide
expectations.]

   4. BGP SPF Peering Models

   For all the peering models, the direct connection discovery and
   liveliness detection for the interconnecting links are independent
   of the BGP protocol and outside the scope of this document. For
   example, liveliness detection could be done using the BFD protocol
   [RFC5880] and connection discovery using [l3dl - Informative
   Reference].

   It is expected that a connection discovery mechanism provides the
   following information: remote link identifiers, ASN, BGP ID, ...


That was a lot shorter in my dream... ;-)

My 2c.

Alvaro.


On March 9, 2023 at 3:45:53 PM, Alvaro Retana ([e-mail])
wrote:

On March 9, 2023 at 2:41:17 PM, Acee Lindem wrote:

Acee:

Hi!

It looks like the review was truncated, you replied up to line 372, but the
complete review goes all the way to line 1513. :-(

  https://mailarchive.ietf.org/arch/msg/lsvr/80Awa3weqFJC5G--ep0EZVYFfmc/


...
> > My main concern is still the lack of semantic checking (see my
> > comments in §7.*). BGP-LS (rfc7752bis) only does syntactic validation
> > because any semantic checking is left to the BGP-LS Consumer (and the
> > specifics left out of scope). The way BGP SPF uses the information is
> > different (all the nodes run SPF), so the validity of the contents
> > need to be verified
>
> Keyur and I discussed and we’re not sure you think is missing.

This is an example (comment at line 1513):

=====
  [major] The validation in rfc7752bis is syntactic, checking that the
lengths
  are ok, etc.  What about semantic validation?  For example, if TLV 516
is
  present, but the value of the ID is 0, what should the receiver do?  Is
the
  TLV valid?  Is the Node Descriptor valid?  Is the NLRI valid?

  This is just an example -- we should go through all the TLVs.  Note that
none
  of the BGP-LS documents talk about semantic validation, so there isn't a
  place to point to :-( because the Consumer is expected to take care of
that -
  - and how it operates is out of scope.  IOW, BGP-LS can be a garbage-in-
  garbage-out transport from a semantic point of view, but BGP SPF can't!
=====



Alvaro.