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 <direc...@openca.org> 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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
