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

[Jordan Head <[e-mail]>]

Hi Alvaro,

Some of the e-mails got truncated as discussion went on. I'm using the original e-mail, but all feedback is based on the larger discussion and most recent comments.

Comments inline as jhead>>

[External Email. Be cautious of content]


On September 13, 2022 at 8:34:50 AM, Jordan Head wrote:

Hi!

...
> > > [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
> jhead>> sending and receiving a TTL/HL of 1 or 255 only.
> jhead>> Also made the same adjustments for how TIEs are exchanged.

Good!

I keep insisting on this because someone is going to ask.

(1) There's no guidance here (or in the applicability draft) about
when to use either option.

    jhead>> I'll bring this up with the applicability authors.

(2) If using a TTL of 1, there are some security threats that are left
open.  For example, it is (relatively) easy to spoof a packet remotely
so that it has a TTL of 1 locally.  Please see the Security
Considerations in rfc5082.  Please include (in the Security
Considerations of this document) how rift mitigates the use of TTL = 1
(if it does) or an acknowledgement that there are some unmitigated
risks.

    jhead>> I've added the following text in the LIE Exchange section

        For implementations that use a TTL or HL of 1, [RFC5082] describes the risks of packets being unintentionally forwarded within a network.

The same questions/concerns apply to TIEs of course.

    jhead>> I've added the same language to the TIE Exchange section as well.

...
> 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
> jhead>> things more clearly. I think the "limited" gives an indication of
> jhead>> flexibility for those that want it. I think "with limited or no
> jhead>> multicast support" works better?
> jhead>>
> jhead>> Obviously most implementations would use IPv6, followed by some IPv4,
> jhead>> but there are platforms that only implement really simple IPv4 stacks
> jhead>> without multicast support (which could be described as "limited or
> jhead>> no"). IoT-style devices come to mind here as an example. My view of
> jhead>> this is that calling it out this way helps bridge the gap between
> jhead>> implicitly vs. explicitly supported and makes things clearer for some
> jhead>> implementors. As you know there are specifications where the language
> jhead>> _technically_ allows for something and others where the language
> jhead>> shows that authors _intentionally_ allow something. I think we fall
> jhead>> into the latter.
> jhead>>
> jhead>>
> jhead>> As a result, I've changed things to the following:
> jhead>>
> jhead>> "A simplified version MAY be implemented on platforms with limited or
> jhead>> no multicast support (e.g. IOT devices) by sending and receiving
> jhead>> LIE frames on IPv4 subnet broadcast addresses and IPv6 all routers
> jhead>> multicast address. However, this technique is less optimal and
> jhead>> presents a wider attack surface from a security perspective."

Ok -- I still don't see the value of this paragraph, but if you want
to include it:

(1) "IPv4 subnet broadcast addresses and IPv6 all routers multicast
address" : Did you want to use "and" here, or "or"?

    jhead>> As Tony stated, it's an or. Text now reads:

        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 or the IPv6 all routers multicast address.

(2) Given that the implementation is optional, but simpler, are there
other cases where this implementation may be used?  This is probably a
topic for the applicability draft -- I didn't see anything explicit
there about this, even in the "IoT Applicability" section.

    jhead>> I'll bring this up with the applicability authors.

(3) The converse question should also be answered: Given that this
technique is "less optimal", when would a node not want to implement
it (assuming it has all the resources needed for a full
implementation)?  Also a topic for the applicability draft.

    jhead>> I'll bring this up with the applicability authors.

(4) "presents a wider attack surface from a security perspective" --
Please include something in the Security Considerations section about
the wider attack surface.

    jhead>> I've added a new sub-section to the "Security Considerations" section called "IPv4 Boradcast and IPv6 All Routers Multicast Implementations". It basically describes the fact that the attack _surface_ is wider, but the specific vectors themselves are already addressed by the preceding sub-sections.

...
> [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
> jhead>> Table 1 caused some confusion outside of its own scope, and after
> jhead>> reading it in conjunction with your comments I realized that my
> jhead>> interpretation may not be the same as everyone elses. I've split this
> jhead>> table into two new tables, one to describe how LIE exchange ocurrs
> jhead>> over different address family combinations and another to factor in
> jhead>> `ipv4_forwarding_capable` in the same context. I may refer to those
> jhead>> new tables in some of my replies.

    jhead>> In another part of this thread, you suggested the following:

        s/mechanism to discover the corresponding IPv6 address/mechanism to discover the corresponding gateway

        Agreed and fixed.


I'll comment on the new tables first (from -16):

1595        +==========+==========+==========================================+
1596        | Local    | Remote   | LIE Exchange Behavior                    |
1597        | Neighbor | Neighbor |                                          |
1598        | AF       | AF       |                                          |
1599        +==========+==========+==========================================+
1600        | IPv4     | IPv4     | LIEs and TIEs are exchanged over IPv4    |
1601        |          |          | only.  TIEs are received on any of the   |
1602        |          |          | LIE source addresses.                    |
1603        +----------+----------+------------------------------------------+
1604        | IPv6     | IPv6     | LIEs and TIEs are exchanged over IPv6    |
1605        |          |          | only.  TIEs are received on any of the   |
1606        |          |          | LIE source addresses.                    |
1607        +----------+----------+------------------------------------------+
1608        | IPv4,    | IPv6     | The local neighbor sends LIEs for both   |
1609        | IPv6     |          | IPv4 and IPv6 while the remote neighbor  |
1610        |          |          | only sends LIEs for IPv6.  The resulting |
1611        |          |          | adjacency will exchange TIEs over IPv6   |
1612        |          |          | on any of the IPv6 LIE source addresses. |
1613        +----------+----------+------------------------------------------+
1614        | IPv4,    | IPv4,    | LIEs and TIEs are exchanged over IPv6    |
1615        | IPv6     | IPv6     | and IPv4.  TIEs are received on any of   |
1616        |          |          | the IPv4 and IPv6 LIE source addresses.  |
1617        +----------+----------+------------------------------------------+

- "TIEs are received on any of the LIE source addresses."

I had to read this several times to understand that it means that the
remote neighbor sends TIEs to any of the local addresses used to send
LIEs.

    jhead>> Well if you're reading it several times, others are too. I've adjusted the language slightly to better convey which node does what for items 1, 2, and, 4. See the new version of the table below:

    +==========+==========+==========================================+
    | Local    | Remote   | LIE Exchange Behavior                    |
    | Neighbor | Neighbor |                                          |
    | AF       | AF       |                                          |
    +==========+==========+==========================================+
    | IPv4     | IPv4     | LIEs and TIEs are exchanged over IPv4    |
    |          |          | only.  The local neighbor receives TIEs  |
    |          |          | from remote neighbors on any of the LIE  |
    |          |          | source addresses.                        |
    +----------+----------+------------------------------------------+
    | IPv6     | IPv6     | LIEs and TIEs are exchanged over IPv6    |
    |          |          | only.  The local neighbor receives TIEs  |
    |          |          | from remote neighbors on any of the LIE  |
    |          |          | source addresses.                        |
    +----------+----------+------------------------------------------+
    | IPv4,    | IPv6     | The local neighbor sends LIEs for both   |
    | IPv6     |          | IPv4 and IPv6 while the remote neighbor  |
    |          |          | only sends LIEs for IPv6.  The resulting |
    |          |          | adjacency will exchange TIEs over IPv6   |
    |          |          | on any of the IPv6 LIE source addresses. |
    +----------+----------+------------------------------------------+
    | IPv4,    | IPv4,    | LIEs and TIEs are exchanged over IPv6    |
    | IPv6     | IPv6     | and IPv4.  TIEs are received on any of   |
    |          |          | the IPv4 or IPv6 LIE source addresses.   |
    |          |          | The local neighbor receives TIEs from    |
    |          |          | the remote neighbors on any of the IPv4  |
    |          |          | or IPv6 LIE source addresses.            |
    +----------+----------+------------------------------------------+

- [nit] s/IPv4 and IPv6 LIE source addresses/IPv4 or IPv6 LIE source addresses

        jhead>> Agreed and fixed.


1619           Table 1: Control Plane Behavior for Neighbor AF Combinations

1621       +==========+==========+=============================================+
1622       | Local    | Remote   | Forwarding Behavior                         |
1623       | Neighbor | Neighbor |                                             |
1624       | AF       | AF       |                                             |
1625       +==========+==========+=============================================+
1626       | IPv4     | IPv4     | Both nodes are required to set the          |
1627       |          |          | `ipv4_forwarding_capable` flag to true.     |
1628       |          |          | All traffic is forwarded over IPv4.         |
1629       +----------+----------+---------------------------------------------+
1630       | IPv6     | IPv6     | If either neighbor sets                     |
1631       |          |          | `ipv4_forwarding_capable` to false, all     |
1632       |          |          | traffic is forwarded over IPv6.  If         |
1633       |          |          | both neighbors set                          |
1634       |          |          | `ipv4_forwarding_capable` to true, IPv4     |
1635       |          |          | traffic can be forwarded.                   |
1636       +----------+----------+---------------------------------------------+
1637       | IPv4,    | IPv6     | If either neighbor sets                     |
1638       | IPv6     |          | `ipv4_forwarding_capable` to false, all     |
1639       |          |          | traffic is forwarded over IPv6.  If         |
1640       |          |          | both neighbors set                          |
1641       |          |          | `ipv4_forwarding_capable` to true, IPv4     |
1642       |          |          | traffic can be forwarded.                   |
1643       +----------+----------+---------------------------------------------+
1644       | IPv4,    | IPv4,    | IPv4 and IPv6 traffic can be forwarded.     |
1645       | IPv6     | IPv6     | The behavior is unspecified if either       |
1646       |          |          | neighbor sets the                           |
1647       |          |          | `ipv4_forwarding_capable` to false.         |
1648       |          |          | The behavior is also unspecified if         |
1649       |          |          | IPv4 and IPv6 advertise different           |
1650       |          |          | flags, as described previously.             |
1651       +----------+----------+---------------------------------------------+

1653             Table 2: Forwarding Behavior for Neighbor AF Combinations

- Case 2: "If either neighbor sets `ipv4_forwarding_capable` to false,
all traffic is forwarded over IPv6."

Saying that "all traffic is forwarded over IPv6" gives the impression
that IPv4 traffic over IPv6 is possible.  I think you mean that "only
IPv6 traffic can be forwarded."  Right?

    jhead>> Correct. Made the following change to both Case 2:

        If either neighbor sets `ipv4_forwarding_capable` to false, only IPv6 traffic can be forwarded. If both neighbors set `ipv4_forwarding_capable` to true, IPv4 traffic is also forwarded via IPv6 gateways.

- In case 3, "If either neighbor sets `ipv4_forwarding_capable` to
false... If both neighbors set `ipv4_forwarding_capable` to true..."

Only the remote neighbor can change the setting.  The local neighbor
is required to set `ipv4_forwarding_capable` to true in both LIEs.

    jhead>> Okay, I see what you mean here. I don't think it benefits us to reitterate the fact that `ipv4_forwarding_capable` MUST be set in both LIEs (at least not here). That said, to keep things unambiguous, I adjusted Case 3 to mention the remote node:

        If the remote neighbor sets `ipv4_forwarding_capable` to false, only IPv6 traffic can be forwarded. If both neighbors set `ipv4_forwarding_capable` to true, IPv4 traffic is also forwarded via IPv6 gateways.

- Case 4: Both sentences say the same thing.


        jhead>> Case 4 now reads:

        IPv4 and IPv6 traffic can be forwarded. If IPv4 and IPv6 LIEs advertise conflicting `ipv4_forwarding_capable` flags, the behavior is unspecified.


The related text, a couple of paragraphs above, is this:

   If IPv4 forwarding is supported on an interface, `ipv4_forwarding_capable`
   MUST be set to true when LIEs from an IPv4 address are sent and MAY be set
   to true in LIEs on IPv6 address if no LIEs are sent from an IPv4 address.
   If IPv4 and IPv6 LIEs indicate contradicting information, protocol behavior
   is unspecified.

It may be good to clarify that "If IPv4 forwarding is supported on an
interface, `ipv4_forwarding_capable` MUST be set to true" for all
LIEs, not just IPv4 LIEs.

    jhead>> Text now reads:

        If IPv4 forwarding is supported on an interface, `ipv4_forwarding_capable` MUST be set to true for all LIEs advertised from that interface.

Going back to the text that I was originally commenting on:

   A node, in case of absence of IPv4 addresses on such links and advertising
   `ipv4_forwarding_capable` as true, MUST forward IPv4 packets using gateways
   discovered on IPv6-only links advertising this capability.


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

>From Table 2, my guess is that "absence of IPv4 addresses" means that
no IPv4 LIEs were sent.  Is that what you mean?

    jhead>> Yes, that's accurate, no IPv4 addresses means no IPv4 LIEs. This is conveyed in a comment below.

> [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
> jhead>> describing the generic behavior in terms of how packets are
> jhead>> forwarded, not the implementation. I've added the following sentence:
> jhead>>
> jhead>> "The specific forwarding implementation to support the described
> jhead>> behavior is out of scope for this document."
> jhead>>
> jhead>> In other words, the behavior is normative (MUST), but the
> jhead>> implementation of it is not (and is out of scope).

Yes, the problem is that the "described behavior" is not fully
described.  This is especially true for a required (MUST) behavior.
How about if we split the difference?


    jhead>> Agreed, here's the resulting text:

        In the absence of IPv4 LIEs with `ipv4_forwarding_capable` set to true, a node MUST forward IPv4 packets using gateways discovered on IPv6-only links advertising this capability. The mechanism to discover the corresponding IPv6 gateway is out of scope for this specification and may be implementation specific.

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

The new text now says:

   (either at least one of the nodes does not advertise MTU in the
   `LiePacket` *or* the advertised MTU values in the `LiePacket`
   element match on both sides) *and*

If one side doesn't advertise an MTU, default_mtu_size is used.  The
other side may advertise anything else and the condition above would
be satisfied.  Why is this ok?

    jhead>> Yes. As Tony mentioned in another part of the thread:

        excellent catch, yes, the “doesn’t advertise” really means we use default value obviously and that has match with the local side (based on normal thrift processing but yes, without making this mental jump it reads the wrong way), I suggest

    jhead>> The resulting text from Tony's suggestion and your comments is:

        (the advertised MTU values in the `LiePacket` element match on both sides while missing MTU in the `LiePacket` is interpreted `default_...`)

Later on, in §4.2.2.1, when defining PROCESS_LIE:

   if both sides advertise MTUs and the LIE has non matching
   MTUs as compared to MTU advertised by this system then
   CLEANUP, PUSH UpdateZTPOffer, PUSH MTUMismatch else

This text also means that there would be a mismatch under the same
conditions as above.  IOW, if advertising the MTU is optional, a node
with an MTU of default_mtu_size can elect to not advertise it (which
is perfectly fine) -- it's neighbors may see something else, but the
mismatch wouldn't be detected.

    jhead>> LIE FSM now covers "missing as default", resulting text now reads:

        if both sides advertise MTU values and the MTU in the received LIE does not match the MTU advertised by the local system *or* at least one of the nodes does not advertise an MTU value and the advertising node's LIE does not match the `default_mtu_size` of the system not advertising an MTU then



Juniper Business Use Only