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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

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


>§3.6.1:

>  +---------------------------------+---------------------------------+
>  | Very Large Global ISP           | 32392                           |
>  | ------------------------------- | ------------------------------- |
>  | Very Large Global ISP           | 29528                           |
>  | ------------------------------- | ------------------------------- |
>....
> ... 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. ...

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


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