Re: [Emu] EAP and Fragmentation

["Dr. Pala" <[e-mail]>]

Hi Alan,

thanks for the answers... aligned with what I thought and they do make 
sense... :D Further considerations inline...

On 2/12/19 11:26 AM, Alan DeKok wrote:
> On Feb 12, 2019, at 12:36 PM, Dr. Pala <[e-mail]> wrote:
> [...]
>> This, led me to my first question: is there a de-facto "standard" way to add Fragmentation support we can just use (without having to re-invent the wheel all the time) ?
>    No.
Too bad... :(
>> If we had such a mechanism, then we could just say "implement the mechanism as defined in ... ". This would definitely help developers that could safely re-use code/libraries. The other approach would be to modify EAP to add Fragmentation support there.
>    I suspect that it's difficult to "modify EAP".  However, adding a standard fragmentation method would be definitely useful.

I agree that (a) it would be useful and (b) it would be difficult to 
modify EAP :D It seems to me that EAP made a too simple header... :D

> [ ... ]
>
>    If it's an EAP type that only appears inside of a TLS tunnel, then don't worry too much about fragmentation.
>
>    If the data you're sending will be larger than 64K, you *will* need to provide your own fragmentation support.  But that's only because the EAP header has a 16-bit "Length" field.
>
Yep, that is why the AVP/TLVs use the internal 'L' bit and the 32bits 
length field to address that. I think that to keep the method simple, we 
will require that the method is executed as an internal method of a 
Tunneled method that provides (a) authentication of the server (and 
optionally of the client), and (b) secrecy of the transferred data.

This allows us to:

  * Remove the support for Fragmentation (but we need to require that
    the data is appropriately handled by the encapsulating method)
  * Do not have to implement crypto-parameters negotiation for the outer
    tunnel

The draft will require a well-written security section to make sure that 
deployments do not use the method without proper security around it.

>> Looking forward to some great guidance and advice :D Also, if you would like to collaborate/contribute, please let me know!
>    I've been known to have opinions.  :)  Plus, it's useful to have credential provisioning methods.
>
... and I've been known to have ears and eyes to listen and read :D That 
works perfectly!

Thanks for the feedback!

Cheers,

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo