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

[Alvaro Retana <[e-mail]>]

On February 9, 2023 at 12:24:27 PM, Antoni Przygienda wrote:


Tony:

Hi!

Some comments below.

Thanks!

Alvaro.


...
> > 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!
>
> Prz> yes, it’s MUST now. Is that enough we reference 5082 and add that TTL 1
> Prz> as choice prevents any packets escaping unintentionally further than 1
> Prz> hop in the network?

TTL 1 prevents packets escaping from the network, it doesn't prevent
packets being unintentionally forwarded into the network.  I think
that is covered in rfc5082.  So, yes, it is ok to point at rfc5082
where the risks are covered.



...
> > jhead>> "A simplified version MAY be implemented on platforms with limited
> > jhead>> or 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"?
>
> Prz> This comes directly from NOK impleneting rift on their virtual platform
> Prz> really so it’s real world input to include this.

I'm not sure if you're saying that the need for a "simplified version"
comes from the real world (which I don't doubt), OR if you were
answering the question and want to use "and".  The latter just seems
unintuitive because you're then sending/receiving two copies.


> (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.
>
> (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.
>
> (4) "presents a wider attack surface from a security perspective" --
> Please include something in the Security Considerations section about
> the wider attack surface.
>
>
> prz> agree on all above. Hence I would leave what is here in the main spec +
> prz> (4) since it’s normative stuff and then all those considerations you
> prz> bring up to be put into app draft.

I hope someone is keeping a list. ;-)



...
> 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?
>
> In the absence of IPv4 LIEs and 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 address is out of scope for this specification
> and may be implementation specific.
>
> prz> well, you do NOT need a v6 address, that’s the trick, you forward v4
> prz> frame as v4 frame using the MAC address resolved over the v6 LIE source,
> prz> be ity LLC or real stuff. No tunneling, no encaps, that’s why it’s so
> prz> interesting.

As we've been discussing, the mechanism is not specified.

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



...
> 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?
>
> Prz> excellent catch, yes, the “doesn’t advertise” really means we use
> Prz> default value obviously and that has match with the local side (based on
> Prz> normal thrift processing but yes, without making this mental jump it
> Prz> reads the wrong way), I suggest
> Prz>
> Prz> (the advertised MTU values in the `LiePacket`
> Prz> element match on both sides while missing MTU in the `LiePacket` is
> Prz> interpreted per normal thrift rules as `default_...`)

Take out "per normal thrift rules".