Re: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT)

[Adam Roach <[e-mail]>]

Alan --

Thanks for the new text. This is a nice set of improvements overall, but 
I still
have concerns relating to the contents of the Operator-NAS-Identifier 
attribute.

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

§3.4:

 >  Length
 >
 >     4 to 23.
 >
 >     Implementations supporting this attribute MUST be able to handle
 >     between one (1) and thirty-two (32) octets of data.

It seems to me that "4 to 23" needs updating here.

I'll note that 32 octets is still too short for modern block-based ciphers
(the "more than" in my "more than 32 bytes" suggestion probably should have
said "much more than."). For example, if someone wanted to use GCM here (as
the text still says "encrypt"), you'd need 32 bytes for the ciphertext, 4 to
32 bytes for the tag, and something on the order of 12 bytes for the IV. 
So it
would be more like 76 bytes rather than 32.

Alternately, and this is my suggestion, remove "encrypt" entirely from this
section, replacing it with "obfuscate." Concretely:

       The second method is to obfuscate the NAS IP address using 
information
       known locally by the Visited network; for example, by XORing it 
with a
       bitmask.  The output of that obfuscation operation is data that 
can be
       used as the value of Operator-NAS-Identifier.  On reception of a CoA
       packet, the locally-known information can be used to un-obfuscate the
       value of Operator-NAS-Identifier, in order to determine the 
actual NAS
       IP address.

Given that we've established that actual encryption isn't necessary 
here, this
seems easier than expanding the field to be large enough to actually encrypt
stuff.

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

§2.1:

 >  In order to determing the "next hop" for a packet, the proxying

Nit: "...determine..."


Thanks!

/a

On 8/15/18 11:37, Eric Rescorla wrote:
> Fantastic. Thanks!
>
> -Ekr
>
>
> On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Aug 15, 2018, at 12:12 PM, Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     >   As such, there is no need for integrity checks, replay
>     detection, privacy, etc.
>     >
>     > OK, well, the text needs to say this, because the existing text
>     implies otherwise.
>
>       I will issue a new version shortly with the offending text
>     removed, and the above text added.
>
>       Alan DeKok.
>
>