Re: [Rift] AD Review of draft-ietf-rift-rift-12 (Part 2a)

[Jordan Head <[e-mail]>]

Hi Alvaro,

We pushed the new version last night (-16), my replies are inline.

Thanks
Jordan

On 7/22/22, 8:00 AM, "Alvaro Retana" <[e-mail]> wrote:

    [External Email. Be cautious of content]


Hi!

I have a couple of replies and then some comments on the updated text in -15.

Thanks!

Alvaro.


...
> > Part 2a starts with §4.2 (Specification) and goes just through §4.2.2 -- I
> > just started reading the LIE FSM/§4.2.2.1. I included a couple of comments
> > on the schema itself.
...


For the Chairs/Shepherd:

> > - §8.1 includes a set of suggested UDP ports, but they are not reflected
> > in the registry. Early allocation has not been requested -- you should
> > consider doing so. See rfc7120.

The same comment applies to the multicast addresses.

    jhead>> Ack.


...
> > [minor] "IPv4 Time to Live (TTL) / IPv6 Hop Limit (HL) of 1" Was GTSM
> > (rfc5082) considered? Several documents (for example, rfc8085 and
> > draft-ietf-opsec-v6) suggest its use. You may be asked about it later. It
> > would be good to preempt those questions by adding some text in the
> > Security Considerations about any risks...or using it.
>
> There is a religious war about 255 vs. 1 since a long time. I personally in
> deployment was hurt @ least twice by implementations ending up not checking
> TTL/misprocessing and forwarding one-hop packets with 254 on unicast/
> multicast. Also, having a buggy FIB looping tightly packets with TTL 255 is
> seldom fun. I never saw a thing not decrementing TTL and dropping on 1. I
> prefer the 1 with possibly a multi-hop spoof (never saw that in my life
> frankly, such an attack is really, really hard to engineer) than a rogue
> packet running away in the network or micro looping 255 times on fast links.
>
> What I saw were replay attacks and against those RIFT is extremely well
> protected as far it's practically implementable. Plus, if one _really_ wants
> security one configures adjacency keys (and RIFT allows a full plethora of
> that) rather than rely on the 255 hack to have "kind of a little lick of
> security".
>
> So if the security folks push on it we can always go to 255 or write that the
> TLL received MUST be either 255 or 1 to satisfy both camps.
...
> > 1500 LIEs arriving with IPv4 Time to Live (TTL) / IPv6 Hop Limit (HL)
> > 1501 larger than 1 MUST be ignored.
> >
> > [major] "MUST be ignored" The specification of the sender (§4.2.2) says
> > that "LIEs SHOULD be sent with an IPv4 Time to Live (TTL) / IPv6 Hop Limit
> > (HL) of 1". This is a Normative conflict because it is only recommended to
> > the sender, but required by the receiver.
>
> aha, yes, very good. I'm reluctant to say MUST since it's not always possible
> on a platform to force TTL (this is UDP). So I make it SHOULD on both sides.
>
> your comment on the 255/1 stands of course.

The text in -15 says:

   LIEs SHOULD be sent with an IPv4 Time to Live (TTL) / IPv6 Hop
   Limit (HL) of either 1 or 255 to prevent RIFT information
   reaching beyond a single L3 next-hop in the topology.

   ...

   LIEs arriving with IPv4 Time to Live (TTL) / IPv6 Hop Limit (HL)
   different than 1 or 255 SHOULD be ignored.


The good thing is that you removed the Normative conflict: both
sentences now say SHOULD.  The bad thing is that, even if providing
more options, anything can be used (1, 2, 4, 56, 123, 254, 255, etc.)
because neither the sender nor the receiver is required to do
anything.

In the reply (above) you suggested using MUST.  That would be a good
start.  But then you also said you were reluctant...

Note that in my original comment I was just asking whether GTSM was
considered and to justify why not (if you had considered and didn't
want to use it), not to add the cumbersome support for both cases.
IOW, do it any way you want, please be clear about any requirement
(MUST), and justify why you're not following what other documents
recommend (if not using 255) and how any issues can be mitigated (or
if they need to be -- see the Security Considerations in rfc5082).

    jhead>> Discussed with Tony and we're good with changing things to MUST for sending and receiving a TTL/HL of 1 or 255 only.
    jhead>> Also made the same adjustments for how TIEs are exchanged.

> > [major] "LIEs SHOULD be sent with network control precedence." When is it
> > ok to not do so? IOW, when is this behavior recommended and not required.
> > BTW, please add a reference.
>
> hard to implement often that's why it's not MUST. will add ref to precedence.

You didn't add a reference.

    jhead>> Added RFC2474 for both TIEs and LIEs as an informative reference as it indicates that NC is "commonly" used for control plane traffic.

*****
What follows are comments on -15 covering the same sections (§4.2
(Specification) through §4.2.2).
*****

[Line numbers from idnits.]


...
1417    4.2.  Specification
...
1423       The FSMs, as usual, are presented as states the FSM can assume,
1424       events that it can be given and according actions performed when
1425       transitioning between states on event processing.

1427       Actions are performed before the end state is assumed.

[nit] Suggestion>
   The FSMs are presented as states a node (?) can be in,
   events that can take place, and resulting actions, which
   are performed before the next state is taken.

    jhead>> Changed to: "...states a neighbor...".

...
1441       Any attempt to transition from a state towards another on reception
1442       of an event where no action is specified MUST be considered an
1443       unrecoverable error, i.e. the protocol MUST reset all adjacencies,
1444       discard all the state and MAY NOT start again.

[major] "MUST be considered an unrecoverable error"

Given that the meaning of this phrase is explained, we don't need
Normative language:  s/MUST/must

    jhead>> Fixed.

[major] "MAY NOT start again"

"MAY NOT" is not an rfc2119 keyword.  I assume you mean that the
behavior is not optional (i.e. mandatory), right?   s/MAY NOT/MUST NOT

    jhead>> This doesn't need to be normative, changed it to "may not".

...
1461    4.2.1.  Transport

1463       All packet formats are defined in Thrift [thrift] models in
1464       Appendix B.  LIE packet format is contained in the `LIEPacket` schema
1465       element.  TIE packet format is contained in `TIEPacket`, TIDE and
1466       TIRE accordingly in `TIDEPacket`, `TIREPacket` and the whole packet
1467       is a union of the above in `ProtocolPacket` while it contains a
1468       `PacketHeader` as well.

[nit] s/ and the whole packet is a union of the above in
`ProtocolPacket` while it contains a `PacketHeader` as well./.  The
whole packet is the union of a 'PacketHeader' and the above.

    jhead>> I re-read this and didn't like how it parsed either, I changed things to this:

        "All RIFT packet structures and their contents are defined in the Thrift models in Appendix B.

        The packet structure itself is defined in `ProtocolPacket` which contains the packet header (`PacketHeader`) and the packet contents (`PacketContent`). `PacketContent` is a union of the LIE, TIE, TIDE, and TIRE packets and are defined in `LIEPacket`, `TIEPacket`, `TIDEPacket`, and `TIREPacket` respectively.

        In terms of bits on the wire, it is the `ProtocolPacket` that is serialized and carried in an envelope defined in..."

...
1477    4.2.2.  Link (Neighbor) Discovery (LIE Exchange)
...
1507       An implementation MAY listen and send LIEs on IPv4 and/or IPv6
1508       multicast addresses.  A node MUST NOT originate LIEs on an address
1509       family if it does not process received LIEs on that family.  LIEs on
1510       same link are considered part of the same LIE FSM independent of the
1511       address family they arrive on.  Observe further that the LIE source
1512       address may not identify the peer uniquely in unnumbered or link-
1513       local address cases so the response transmission MUST occur over the
1514       same interface the LIEs have been received on.  A node MAY use any of
1515       the adjacency's source addresses it saw in LIEs on the specific
1516       interface during adjacency formation to send TIEs (Section 4.2.3.3).
1517       That implies that an implementation MUST be ready to accept TIEs on
1518       all addresses it used as source of LIE frames.

[major] "An implementation MAY listen and send LIEs on IPv4 and/or
IPv6 multicast addresses."

Sorry to come back to this, but it's really bothering me.  After
reading this multiple times I figured out what is the problem: Yes,
it's optional to listen/send on IPv4 and/or IPv6 -- I too like the
flexibility.  *But*, for rift to work there's an expectation that at
least one will be used.  IOW, while the selection is flexible,
selecting (at least) one AF is *not* optional (otherwise the protocol
doesn't work).

The "MAY" above is not a Normative statement because one AF (or both)
should be used.  The sentence is really just a statement of fact: any
(or both) AF can be used.

All this is to suggest this change: s/MAY/may

    jhead>> Fixed.

[major] "MAY use any of the adjacency's source addresses it saw in
LIEs...to send TIEs."  This use of "MAY" makes using the source
address from a LIE optional.

§4.2.3.3 says that "TIEs...using the
destination address on which the LIE adjacency has been formed", which
doesn't make the use optional.

I'm also revisiting this -- again, statement of fact, not an option: s/MAY/may

    jhead>> Fixed.

1520       A simplified version on platforms with limited multicast support MAY
1521       implement optional sending and reception of LIE frames on IPv4 subnet
1522       broadcast addresses and IPv6 all routers multicast address though
1523       such technique is less optimal and presents a wider attack surface
1524       from security perspective.

[major] Ahhh...mmmm...

Let's start with this: I'm not sure how to read this sentence, a few
commas would help.

You don't need to solve all the cases.  What is "limited multicast
support"?  As I interpret the sentence, IPv6 seems to support
multicast so the choice is simple: use IPv6.  As you explain, the node
doesn't have to use both.

The phrase "MAY implement optional..." is a double indication that
"sending and reception" is optional: you don't have to.  Which seems
to point to the obvious conclusion of use IPv6.

In summary, I don't understand the value of this sentence, including
the use of a normative MAY ... but maybe I just don't understand the
sentence itself. :-(

    jhead>> I think the main solution here would be for us would be to convey things more clearly. I think the "limited" gives an indication of flexibility for those that want it. I think "with limited or no multicast support" works better?

    Obviously most implementations would use IPv6, followed by some IPv4, but there are platforms that only implement really simple IPv4 stacks without multicast support (which could be described as "limited or no"). IoT-style devices come to mind here as an example. My view of this is that calling it out this way helps bridge the gap between implicitly vs. explicitly supported and makes things clearer for some implementors. As you know there are specifications where the language _technically_ allows for something and others where the language shows that authors _intentionally_ allow something. I think we fall into the latter.

    As a result, I've changed things to the following:

        "A simplified version MAY be implemented on platforms with limited or no multicast support (e.g. IOT devices) by sending and receiving LIE frames on IPv4 subnet broadcast addresses and IPv6 all routers multicast address. However, this technique is less optimal and presents a wider attack surface from a security perspective."


1526       A ThreeWay adjacency (as defined in the glossary) over any address
1527       family implies support for IPv4 forwarding if the
1528       `ipv4_forwarding_capable` flag in `LinkCapabilities` is set to true.
1529       A node, in case of absence of IPv4 addresses on such links and
1530       advertising `ipv4_forwarding_capable` as true, MUST forward IPv4
1531       packets using gateways discovered on IPv6-only links advertising this
1532       capability.  It is expected that the whole fabric supports the same
1533       type of forwarding of address families on all the links, any other
1534       combination is outside the scope of this specification.
1535       `ipv4_forwarding_capable` MUST be set to true when LIEs from a IPv4
1536       address are sent and MAY be set to true in LIEs on IPv6 address if no
1537       LIEs are sent from a IPv4 address.  If IPv4 and IPv6 LIEs indicate
1538       contradicting information protocol behavior is unspecified.

[major] "absence of IPv4 addresses...and advertising
`ipv4_forwarding_capable`...MUST forward IPv4 packets using gateways
discovered on IPv6-only links"

    jhead>> Allow me to preface a couple of things. I think it's obvious that Table 1 caused some confusion outside of its own scope, and after reading it in conjunction with your comments I realized that my interpretation may not be the same as everyone elses. I've split this table into two new tables, one to describe how LIE exchange ocurrs over different address family combinations and another to factor in `ipv4_forwarding_capable` in the same context. I may refer to those new tables in some of my replies.

Just to be clear, the choice of which AF to use when sending LIEs is
up to the nodes -- which then means that nodes may decide (or be
configured) to only use IPv6 with RIFT, even if IPv4 is configured on
the interface.  Right?  I assume that's true because it is the third
case shown in Table 1.

    jhead>> Correct, neighbors may exchange LIEs over IPv6 with `ipv4_forwarding_capable` set in order to exchange IPv4 traffic without an IPv4 LIE exchange.

IOW, not having IPv4 configured ("absence of IPv4 addresses") is not
the only case where ipv4_forwarding_capable can be set, and also not
the only case where the interface will support v4overv6.  This will
also happen if the LIEs/TIEs are only advertised over IPv6 (regardless
of which AFs are supported/configured on the interface).

The sentence above is then misleading because it mandates the v4overv6
behavior only in the "absence of IPv4 addresses".

    jhead>> The word choice here is intentional: "absence of IPv4 addresses" does not mean IPv4 isn't configured on an interface. I think the new Table 2 will help clear some of this confusion up.

[major] "MUST forward IPv4 packets using gateways discovered on IPv6-only links"

I assume that this means that the IPv4 packet is encapsulated in IPv6
and sent to a link-local address -- is that what you mean?  Using
"gateways discovered" may give the impression that there's more
involved.  You may want to consider being explicit about the
operation.

Also, in Figure 1 the text (for the 3rd case: IPv4/IPv6 over IPv6)
simply says "IPv4 is forwarded", giving the wrong impression that the
IPv4 is natively (not encapsulated) forwarded.

At some point we talked about the fact that forwarding is out of scope
-- that's ok.  I'm calling out this text because it requires
forwarding ("MUST forward").  Please make the behavior non-normative
and declare the specific mechanism to "forward IPv4 packets...on
IPv6-only links" out of scope.

    jhead>> I'd like to point you to the new Table 2 again here. We are describing the generic behavior in terms of how packets are forwarded, not the implementation. I've added the following sentence:

        "The specific forwarding implementation to support the described behavior is out of scope for this document."

    jhead>> In other words, the behavior is normative (MUST), but the implementation of it is not (and is out of scope).

[minor] s/`ipv4_forwarding_capable` MUST be set to true when LIEs from
a IPv4 address are sent and MAY be set to true in LIEs on IPv6 address
if no LIEs are sent from a IPv4 address./If IPv4 forwarding is
supported on an interface, `ipv4_forwarding_capable` MUST be set to
true when LIEs from a IPv4 address are sent and MAY be set to true in
LIEs on IPv6 address if no LIEs are sent from a IPv4 address.

    jhead>> Fixed.

[nit] s/information protocol/information, protocol

    jhead>> Fixed.

1540       Operation of a fabric where only some of the links are supporting
1541       forwarding on an address family or have an address in a family and
1542       others do not is outside the scope of this specification.

[] I think it's ok to leave the operation of the fabric out of scope,
but the ability to forward IPv4 traffic without having it configured
means that there are some operational aspects that are left out, and
which are not clearly specified anywhere else (as in not even in other
specifications).

For example, take a look at §3/rfc9229 (IPv4 Routes with an IPv6 Next
Hop in the Babel Routing Protocol).  The intent is not to compare,
just to point out a recent example of something similar which resulted
in significant discussion during IESG Evaluation.

I don't expect any action, just something to keep in mind if it comes up later.

    jhead>> Okay, noted.

...
1550          +=======+=======+=============================================+
1551          | AF    | AF    | Behavior                                    |
1552          +=======+=======+=============================================+
1553          | IPv4  | IPv4  | LIEs and TIEs are exchanged over IPv4, no   |
1554          |       |       | IPv6 forwarding.  TIEs are received on any  |
1555          |       |       | of the LIE sending addresses.               |
1556          +-------+-------+---------------------------------------------+
1557          | IPv6  | IPv6  | LIEs and TIEs are exchanged over IPv6 only, |
1558          |       |       | no IPv4 forwarding if either of the         |
1559          |       |       | `ipv4_forwarding_capable` flags is false.   |
1560          |       |       | If both `ipv4_forwarding_capable` flags are |
1561          |       |       | true IPv4 is forwarded.  TIEs are received  |
1562          |       |       | on any of the LIE sending addresses.        |
1563          +-------+-------+---------------------------------------------+
1564          | IPv4, | IPv6  | LIEs and TIEs are exchanged over IPv6, no   |
1565          | IPv6  |       | IPv4 forwarding if either of the            |
1566          |       |       | `ipv4_forwarding_capable` flags is false.   |
1567          |       |       | If both `ipv4_forwarding_capable` are true  |
1568          |       |       | IPv4 is forwarded.  TIEs are received on    |
1569          |       |       | any of the IPv6 LIE sending addresses.      |
1570          +-------+-------+---------------------------------------------+
1571          | IPv4, | IPv4, | LIEs and TIEs are exchanged over IPv6 and   |
1572          | IPv6  | IPv6  | IPv4, unspecified behavior if either of the |
1573          |       |       | `ipv4_forwarding_capable` flags is false or |
1574          |       |       | IPv4 and IPv6 advertise different flags as  |
1575          |       |       | described previously.  IPv4 and IPv6 are    |
1576          |       |       | forwarded.  TIEs are received on any of the |
1577          |       |       | IPv4 and IPv6 LIE sending addresses.        |
1578          +-------+-------+---------------------------------------------+

[minor] Two of the columns have an "AF" header.  It is not clear (just
from the header) how their meaning is different.  Please clarify.

I'm assuming that the first column shows the AFs enabled on the
interface, and the second one shows the AF used to exchange TIEs/LIEs.
Or does the first column represent which AFs are intended to be
forwarded (to cover the "absence of IPv4 addresses")?   In either
case, it looks like the table may be incomplete.

    jhead>> Agreed, this Table wasn't clearly defined. In the original version the left/right columns correspond to local/remote neighbors and their configured address families. I've clarified this in the new tables.

[minor] The Behavior of the second and third cases is the same, which
adds to my question about what the AF columns mean.  Are the columns
representing only one side?

    jhead>> Should be cleared up by the above changes.

[nit] Case 4: "IPv4 and IPv6 are forwarded."

The placement of this sentence after the behavior of
ipv4_forwarding_capable is explained (again) gives the impression that
IPv4 and IPv6 are always forwarded.

    jhead>> Should be cleared up by the above changes.

[minor] Related question, so I don't forget later.  In Case 2
(IPv6/IPv6), for example, if only one side sets
ipv4_forwarding_capable, I'm assuming the TIEs won't include any IPv4
information.  Is that true?  Where is that specified?  It seems
obvious, but it would be nice if it was explicitly specified
somewhere.

    jhead>> Should be cleared up by the above changes.

...
1608       A node MUST form a ThreeWay adjacency (or in other words consider the
1609       neighbor "valid" and hence reflecting it) if and only if the
1610       following first order logic conditions are satisfied on a LIE packet
1611       as specified by the `LIEPacket` schema element and received on a link

[] -12 (the last version I had looked at) listed a couple of
conditions related to the PoDs:

   A node tries to form a three-way adjacency if and only if

   1.  the node is in the same PoD or either the node or the neighbor
       advertises "undefined/any" PoD membership (PoD# = 0) AND

   ...

   3.  the neighbor is not member of some PoD while the node has a
       northbound adjacency already joining another PoD AND


Are these conditions not needed any more?  I know they were taken off
because I was confused with them -- but I guess that the text (in -12)
about how they could be "optionally disregarded" made them not
required.

Just checking...

    jhead>> Correct, they're not required for implementation, existing LIE validation will keep the topology conformant.

...
1616       2.  the neighboring node uses a valid System ID (i.e. value different
1617           from `IllegalSystemID`) in `sender` element in `PacketHeader`
1618           *and*

[nit] s/in `sender` element/in the `sender` element

    jhead>> Fixed.

1620       3.  the neighboring node uses a different System ID than the node
1621           itself

[nit] For consistency, looks like you're missing an "*and*".

    jhead>> Fixed.

1623       4.  the advertised MTUs in `LiePacket` element match on both sides
1624           *and*

[major] This clause talks about the "advertised MTUs", but advertising
the MTU is optional.

Suggestion>
   the MTU on on the link (either advertised in the `LiePacket`
   element or the 'default_mtu_size') matches on both sides *and*

    jhead>> Added language to clarify.


[EoR P2a-15]


Juniper Business Use Only