Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)

[Alan DeKok <[e-mail]>]

On Aug 14, 2018, at 11:51 AM, Adam Roach <[e-mail]> wrote:
> I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set.
> 
> The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it?

  The Operator-NAS-Identifier may contain information, such as an encrypted IP address.  In which case it should use sane encryption methods.

  If it's just an opaque token, then the token value should be created via some sane method.  Mainly to avoid accidental re-use.

> The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it?

  The visited network needs to know that the token maps to an actual NAS.

  If the token is an encrypted blob, it can decrypt the blob and verify it that way.  If the token is an opaque value, then the network needs to store the values it sends out.  Incoming values are then checked against the list to see if they're known.

  I think part of the confusion is that I don't want to restrict how people use it.  It might be simpler to just give one recommendation, and leave it at that.

  Alan DeKok.