Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

Sam,

While I understand your preference, it does mean that there cannot be a max
4K buffer in a server that supports both DTLS and non-DTLS clients in the
UDP processing code.   The UDP processing code does not know if this is a
DTLS or a non-DTLS message and thus you can end up in a situation where a
>4K buffer is received in the UDP processing code and passed directly to the
non-DTLS processing and have a potential buffer overflow.  Using a maximum
buffer size on the wire does prevent that problem.

On the other hand, I think you might be correct that requiring a 4K buffer
on the data is correct behavior since if you go from a non-DTLS link to a
DTLS link then you go from a 4K data buffer to a less than 4K data buffer
size then leading to delivery problems.

On the whole I do support this but it could be an implementation issue.
Alan do you think this is a major implementation problem?

Jim

> -----Original Message-----
> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf
> Of Sam Hartman
> Sent: Wednesday, April 03, 2013 7:45 AM
> To: Alan DeKok
> Cc: radext@ietf.org; Peter Deacon; radext-chairs@tools.ietf.org
> Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04
> 
> >>>>> "Alan" == Alan DeKok <aland@deployingradius.com> writes:
> 
> 
>     Alan>   It's a trade-off with implementations.  The specs say max 4K
>     Alan> RADIUS packets.  However, implementations may interpret this
>     Alan> as max 4K buffer for UDP application data.  In which case the
>     Alan> DTLS overhead requires that the encapsulated RADIUS packet is
>     Alan> smaller.
> 
> My preference is that the spec forbid receivers from making this choice.
> That is, I'd prefer that receivers MUST support a 4k RADIUS payload and
thus
> MUST support the necessary room for the DTLS overhead.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext