Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Sue,

On Thu, Apr 23, 2020 at 03:19:45PM -0400, Susan Hares wrote:
> Ben:
> 
> First of all thank you for your detailed review.   
> 
> We really appreciate this detailed review during a revision of a deployed
> protocol. 

I'm regularly surprised by what sorts of things can become stale in -bis
documents -- the usual culprit is IANA considerations, but sometimes there
are stale references or section numbers in references, so I try to read
through the whole thing if I have time.

> Christoph has added each of your comments to the github repository for this
> draft. 
> 
> 
> Two clarifying questions that need pulling out besides your DISCUSS. 
> (see Robert's comment on the RR implication on the DISCUSS). 
> I'm pulling these to the front for ease of responding to the 
> 
> Section 12: 
> Your comment: 
> I'd consider mentioning again that some of the NRLI components won't work
> properly on fragmented traffic and that unexpected fragmentation can cause
> DoS.  (This is particularly relevant for IPv4, as opposed to IPv6, where
> fragmentation can occur anywhere on the path.)
> --------
> Clarifying questions: 
> The RFC5575bis (and RFC5575) is simply providing filters for a firewall
> function. 
> Is there an RFC that suggestions the appropriate cautions for firewall
> filters.? 
> If so, could we mention that people implementing RFC5575bis should 
> simply be aware of BCPs regarding firewalls regarding DoS? 

I don't know offhand of a good reference for this point (but maybe one of
my fellow ADs does!) -- my sense is that it's mostly just general
institutional knowledge.  For example, RFC 7597 mentions the need to
reassemble before tunneling fragmented packets, and RFC 4301 has extensive
discussion about fragment handling in IPsec and the design rational.  So I
was mostly just envisioning a single sentence along the lines of "Note that
selectors that match on port number will match only the first fragment of
fragmented packets, which may not be the desired behavior when
fragmentation occurs".

> Your comment: 
> Is it worth saying anything about how the RT-redirect actions can direct
> traffic to an entity not expecting it (and, as such, potentially DoS them)?
> 
> Clarifying question 
> Redirect also occurs with the firewalls?  
> RFC5575bis is simply enabling that function with multicast of the 
> Filter prefixes.   Is there a BCP regarding firewalls that use redirect?    

Similarly to the above, I don't know of one offhand.
(I'm also not sure that it's even worth mentioning this topic in the
document -- it's getting a bit far afield.)

> I have been trying to monitor the new threats discussion. 
> 
> Your comment: 
> :It also struck me as noteworthy that we're letting DSCP values creep out of
> a single administrative scope -- the filtering of inbound DSCP markings
> should probably be consistent with the traffic markings advertised to that
> peer." 
> 
> The DSCP markings seem to cross boundaries with MPLS. 
> If there is a BCP regarding DSCP marking, should we reference this as well? 

Interestingly, I don't see such a BCP, and the best references here might
be the original protocol spec/architecture (2474/2475) that discuss ingress
and classifier behavior to enforce policy.  RFC 4594 has something pretty
close, though, for many of the service classes:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods, defined in
      [RFC2475].

So perhaps this document would say something like "when advertising
extended communities for traffic-marking with DSCP, an AS should ensure
that the advertised values will be accepted by its DSCP ingress policy and
classifiers, per [RFC 2475]".

Sorry that I don't have great answers for most of these,

Ben