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

[Alvaro Retana <[e-mail]>]

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.



...
> > [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).



> > [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.



*****
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.


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


[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



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



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


[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



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



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"

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.

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".


[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.


[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.


[nit] s/information protocol/information, protocol



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.



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


[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?


[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.


[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.



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



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



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*".



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*


[EoR P2a-15]