[anonsec] AD Review: Probably and Applicability Statement

[Sam Hartman]

>>>>> "Yu-Shun" == Yu-Shun Wang <wang.yushun at gmail.com> writes:

    Yu-Shun> Hi Sam, Thanks for the reviews. Some comments inline.

    Yu-Shun> Unless someone can provide citations, I am going to
    Yu-Shun> replace these terms as below:

    Yu-Shun> s/flash crowd/unexpected surge of legitimate requests/
    Yu-Shun> s/zombies/compromised systems/ s/DDoS/distributed denial
    Yu-Shun> of service/

    Yu-Shun> (Seriously, do we still have to explain DDoS here? Or we
    Yu-Shun> just need to spell it out?)

Spelling it out is sufficient.
    >> I wonder if the working group has adequately reviewed section
    >> 5.7.  In particular do we actually have a strong consensus that
    >> caching of BTNS credentials is inappropriate?  We certainly
    >> have a lot of issues to work through before we can recommend
    >> this caching. But if there is no caching how is that leap of
    >> faith at all?

    Yu-Shun> At our original draft draft, I left it as "?" (or TBD) We
    Yu-Shun> can change it back to TBD.

    Yu-Shun> The text (as I remembered) deliberately does NOT take a
    Yu-Shun> position on the debate of what LoF is between the two
    Yu-Shun> mechanisms: accepting the unauth ID vs. caching it (and
    Yu-Shun> treating it differently next time). We just explained
    Yu-Shun> what the two mechanisms are and stated the status of our
    Yu-Shun> understanding. I am personally neutral to this.  It's the
    Yu-Shun> WG's call.

    Yu-Shun> By the way, we (the authors) went through a lot of
    Yu-Shun> discussion to keep the position neutral, stating the
    Yu-Shun> issues involved and what will need to happen (at a very
    Yu-Shun> high level) to make it work or secure. IIRC we didn't
    Yu-Shun> shut the door so to speak.

That's not how the section currently reads at all.
The last sentence tries to keep the door open but really does not interact well with the table where you say that  caching cannot be done in BTNS.

The section also does not discuss the  problems with unauthenticated credentials.
IT says what extra work is needed but not really why.
Extra work includes:

* A Mechanism for user acceptance before caching
* How do you know when you are talking to the same peer (mobility/address ownership issues)
* How do you support key rollover/what do you say about this

IMHO, you're not done with this section.  If the authors don't have the experiense internally to complete this section then the WG needs to provide that.

    >> Section 6 rules mobility, nat and multihoming out of scope.
    >> Please provide an argument that btns does not make issues
    >> associated with nat and multihoming worse.  IN particular think
    >> about address selection for inner addresses with anonymous open
    >> services and show that this problem is not worse in a BTNS
    >> universe.

    Yu-Shun> I am no expert to all of those. Text suggestion?

You need to get someone to do the engineering work first.  I.E. I
think it may well be the case that BTNS creates problems in these
areas that need to be addressed.  Someone in the WG actually needs to
work through these issues enough to figure out whether that's the
case.  I simply provided requirements you'd need to meet if you want
to take the current direction.

    Yu-Shun> (I thought those were not in the charter, didn't realize
    Yu-Shun> we have to explain why they are not in the charter.)

As far as I can tell the charter does not speak to these issues one
way or the other.  If you think it does please point out the text in
the charter that speaks to this issue so I can take a look at whether
I'm asking you to go beyond your charter.

    Yu-Shun> Thanks,

    Yu-Shun> yushun

Thanks again for excellent work.