Subject: [OPSEC] Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 20 Aug 2019 20:29:08 -0700

Adam Roach has entered the following ballot position for
draft-ietf-opsec-urpf-improvements-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a clearly written document. My understanding of routing is pretty
simplistic, and I still found the technique well-explained and easy to follow.
This is no small feat. The one term I had to go searching for was "stub AS". If
this is a generally known term, that's fine -- but if not, it may warrant a
short definition or citation.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§3.3:

I believe I understand how the described Algorithm B, is applied by AS4, will
result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about
the means by which AS2 will accept them such that they could be delivered to
AS4.  Is there an assumption that AS2 is employing an ACL-based approach? If
so, this should probably be stated explicitly. (This might be implied by text
elsewhere, in which case I apologize for my confusion; although it may still be
worth explicitly explaining.)

---------------------------------------------------------------------------

§3.5:

>  It is worth emphasizing that an indirect part of the proposal in the
>  draft is that RPF filters may be augmented from secondary sources.

Nit: "the draft" won't age gracefully. I suggest changing to "this document"
or somesuch.

---------------------------------------------------------------------------

§3.6.1:

>  +---------------------------------+---------------------------------+
>  | Very Large Global ISP           | 32392                           |
>  | ------------------------------- | ------------------------------- |
>  | Very Large Global ISP           | 29528                           |
>  | ------------------------------- | ------------------------------- |

I suspect there was a transcription error copying these lines from the source
material, as the appearance of two rows with identical labels seems unlikely
to be intended. I skimmed the cited source material to see if I could figure
out what happened here, but found neither of these numbers (nor any mention of
"Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a
fix. I did find that adding the numbers in the first column on slide 6
yielded 32393, which is tantalizingly close to the first number, but that
might just be a coincidence.

---

From: Jeff Haas <[email-masked]>
Date: Wed, 21 Aug 2019 18:55:30 +0000

Adam,

> On Aug 20, 2019, at 23:29, Adam Roach via Datatracker <[email-masked]> wrote:
> 
> §3.3:
> 

For the examples, it's not important whether AS2 or AS3 are filtering.  However, even if they are, there's sufficient information in the routing for it to work.

BGP NO_EXPORT community means that routes received from AS1 at AS2 are not propagated to AS4.  So, we can use one of the routing based mechanisms.

BGP does have an additional community, NO_ADVERTISE that wouldn't work well for this example.  This would prevent propagation of P1,P2 to other routers in AS2.  However, even that may be fine depending on where uRPF is applied; typically that's only AS border routers.

> might just be a coincidence.

I believe a proper reading of this is that each row is a distinct service provider.  Perhaps updating the labeling to Very Large Global ISP1/2 would be helpful?

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 21 Aug 2019 22:45:39 +0000

Hi Adam,

Thank you for the comments.

>Thanks for a clearly written document. .....

Thank you. Nice of you.

>The one term I had to go searching for was "stub AS". ....

I have defined stub AS in my author's draft for the next version. Done.

>.... Please use the boilerplate from RFC 8174.

Yes, done.

> §3.3:
>I believe I understand how the described Algorithm B, is applied by AS4, .....

I think Jeff has addressed this quite well. Please let us know if you've further questions.

> .... Nit: "the draft" won't age gracefully. I suggest changing to "this document" or somesuch.

Yes. Now the sentence has "this document".

>....
> ... I did find that adding the numbers in the first column on slide 6
>might just be a coincidence. ...

You guessed it right where 32392 came from.
And your math is better than ours :)   32393 is the correct number.
Like Jeff has observed already, each line in the table corresponds
to a unique ISP; so those first two lines in the table now read:

>  | Very Large Global ISP X   |       32393                           |
>  | Very Large Global ISP Y   |       29528                           |

Thanks for the catch. I've updated the draft accordingly.

(I have not made any comments inline below.)

Sriram
----------------------------

§3.3: