Subject: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.txt]

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Mar 2015 14:22:58 -0700

>
>
>
> >
> > Section 6.1:
> >
> > "If a STUN client needs to send requests that are larger than the MTU,
> >  or if an application envisions that a response would be larger then
> >  the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as
> >  transport, unless the purpose of sending an oversized packet is to
> >  probe for MTU characteristics (see [RFC5780])."
>
> So, SCTP is used here purely as a tool to solve the fragmentation
> problem ? Right ?
>

I understand the intent here, but this seems like a very heavyweight
solution to what seems like an edge case. Is anyone planning to actually
implement this, and if so, could you describe the situation where this is
actually encountered?

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 12 Mar 2015 23:42:59 -0700

> implement this, and if so, could you describe the situation where this is

I agree that this solution sounds like an overkill.

I am not sure about a potential implementation. Implementing
SCTP-over-UDP may not be that easy. I am still researching but it
seems like the standard Linux and FreeBSD network library suite does
not have off-the-shelf "tunnelling" SCTP-inside-something solution (I
may be wrong). The available headers and libraries are mostly for the
"native" SCTP networking. Definitely, that complicates the
implementation and adds extra dependencies on the third-party
libraries (if there are any available).

Oleg

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 13 Mar 2015 09:35:55 +0100

On Thu, 12 Mar 2015 23:42:59 -0700
Oleg Moskalenko <[email-masked]> wrote:

> >> > "If a STUN client needs to send requests that are larger than
> >> > the MTU, or if an application envisions that a response would be
> >> > larger then the MTU, then it MUST use SCTP-over-UDP or
> >> > SCTP-over-DTLS-over-UDP as transport, unless the purpose of
> >> > sending an oversized packet is to probe for MTU characteristics
> >> > (see [RFC5780])."
> >>
> > solution to what seems like an edge case. Is anyone planning to
> > actually implement this, and if so, could you describe the
> > situation where this is actually encountered?
> >
> 

Hi Oleg,

there is indeed a third-party library available that can be used for
the purpose, the user-space usrsctp code that can be found here:
https://code.google.com/p/sctp-refimpl/

Lorenzo

> Oleg
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 13 Mar 2015 08:50:39 -0700

> On Mar 13, 2015, at 1:35 AM, Lorenzo Miniero <[email-masked]> wrote:
> 

Lorenzo, thanks for the information, i'll check it.

Oleg

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Mar 2015 12:09:31 -0400

Le 2015-03-12 17:22, Justin Uberti a écrit :
> implement this, and if so, could you describe the situation where this
> is actually encountered?

I think the rationale is "If you care so much about MTU, then use SCTP.
If not, then just limit the size of your packets like everybody else does."

Personally I just limit the size of my packet and I sleep very well at
night...

Simon

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Mar 2015 09:38:18 -0700

Right, that was my reading as well. So my question is, who is being kept
awake by this?

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 13 Mar 2015 10:44:16 -0600

> Right, that was my reading as well. So my question is, who is being kept

draft-ietf-tram-stun-origin

>> Personally I just limit the size of my packet and I sleep very well at

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Mar 2015 09:54:38 -0700

As an author on that document, I don't think there is any real-world
situation where it causes MTU problems.

On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> actually
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJVAxPfAAoJECnERZXWan7En2UP/ioFCFJaUtqBTx9hcudbJE24
> kyqmNEvo6jemxCfaMTlP3gYDaFEC2Yd3Bdp2SGR+e4mvvfVGIxG4gMYWJrRN86Ni
> fy8m1b/xlxjrJhF3bG3E6m10CYZtWIi3sfaqP3EI3NFEvm3Z/+/4Oc91h4dBURpG
> xfKwgugvTDq6hP1+9WoQs7jMjQCMoh70Umk07R2tg5V+Ut7IQcpKf04IScy67PUp
> WcEnseOiyeqjawJ3THmx8eU7GlyKZ5gJ7J5h6I0xxRHqDmRQ/lpZFi6T1M8yib7u
> jd15nknaZMrSWVsWyrYwjKUo1FLMwJogWOZ+XRwtFF8/QvhcWYce2PyYEtG90a0v
> 0fAK0OnhLb0DdcdoAOljwmX5kk0QI2Ti5FlzLrpn3wzKkjYp9AsY5PqSM+bpGLo+
> qr1IAcQ5bkZ1LLx66EyyaRFWWo5jUO6ZLkmGREK6qopN7oAggmZN7YLwna91I9iF
> VONblwac5Xa3XdKwJ9Fxb8jv0z1rqvQhN94UJ0Lov94JZjccbofFhl+G4fhfjH5f
> J9xFQHUJcGgl0vY4CIUEkfe8pU82B5EedTvyoeEkKPckRh7ZF9wz2AMcF61gYtOx
> iHan3o7nqdxgh6CO7nMVG8o1R1UwcInBxC0p2izd3ZpPAA3gTGkNTCNtIpKuYpcb
> ADOtDb6h5RLH5oO14TPS
> =00L/
> -----END PGP SIGNATURE-----
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 13 Mar 2015 09:58:44 -0700

> draft-ietf-tram-stun-origin

that's just a few extra bytes in the ALLOCATE request

---

From: Brandon Williams <[email-masked]>
Date: Fri, 13 Mar 2015 13:17:36 -0400

If the MTU problem is for data packets, then I agree that the approach 
you describe is reasonable. It's easy enough (by some definition of 
easy) to limit packet sizes for the data, and an application that can't 
do that needs some solution to the problem.

It's not so easy to limit packet sizes for allocation requests when you 
think about all the new attributes that might get added to allocation 
requests. The problem I have with the SCTP approach is that it requires 
using SCTP for the whole session just to resolve some packet size issues 
for a very small number of control messages. It would be good to also 
define a solution that applies just to the control messages without 
requiring the data transport to be impacted.

--Brandon

On 03/13/2015 12:09 PM, Simon Perreault wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=AwIF-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=BS30IB4olekwhkm34WEi9ZeMFTC1tRBGAjKL0UDHYe4&s=0n9u1qdhlITCC2XUHi-tl5xKy74rseDmIodfCtXJ5bU&e=
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 13 Mar 2015 11:25:29 -0600

On 03/13/2015 11:17 AM, Brandon Williams wrote:
> If the MTU problem is for data packets, then I agree that the approach you describe is reasonable. It's easy enough (by some definition of easy) to limit packet sizes for the data, and an application that can't do that needs some solution to the problem.
> 
> It's not so easy to limit packet sizes for allocation requests when you think about all the new attributes that might get added to allocation requests. The problem I have with the SCTP approach is that it requires using SCTP for the whole session just to resolve some packet size issues for a very small number of control messages. It would be good to also define a solution that applies just to the control messages without requiring the data transport to be impacted.

That's a TURN problem, but I do not see any issue on having it saying that the packets sent over the TURN channels (which are not STUN based) are sent over [DTLS over] UDP.

- -- 
Marc Petit-Huguenin

---

From: Brandon Williams <[email-masked]>
Date: Fri, 13 Mar 2015 13:38:04 -0400

According to the current stunbis draft, it is still a requirement to 
keep your request down below 548 bytes for IPv4 if you don't know the 
real MTU and your request is not directly associated with MTU discovery. 
The value for the ORIGIN attribute could consume nearly half of that and 
the 3rd party auth token could consume nearly half of the remainder. If 
we don't think that 548 bytes is a reasonable requirement for the 
unknown MTU case, then the requirement should be removed from the spec.

Regarding Justin's question about who is being kept awake by this ... I 
know that small MTUs occur in some parts of the Internet, even as low as 
the IPv4 minimum. I don't think this it's common, but I unfortunately 
don't have numbers to quantify the scope of the problem so my assessment 
is based on a faint memory from a few years ago where I had to allow 
packet fragmentation in these cases in order to avoid dropping the 
packets entirely. I would rather send fragments than drop the whole 
packet, at least for the applications that I support today, and again, I 
believe the issue to be rare.

As per my previous e-mail, I'm more concerned about control messages 
than I am about data messages, since I think there's less flexibility 
around the message size. If the control message gets fragmented, on some 
paths it just won't get through. I would be happy enough with an 
solution for control messages, but even that I don't consider to be 
critical at the moment.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 13 Mar 2015 13:43:53 -0400

Sure, turnbis could describe a split transport where control messages 
are sent using SCTP and data messages are sent without if the 
application can ensure the data messages don't exceed the MTU.

I still think SCTP is a heavy weight solution to solve a STUN issue that 
only impacts a very small number of messages (perhaps just one or two in 
the whole session). Maybe I'm just over-estimating the level of complexity.

--Brandon

On 03/13/2015 01:25 PM, Marc Petit-Huguenin wrote:
> iQIcBAEBCAAGBQJVAx2JAAoJECnERZXWan7EqvEP/RHtwJivSd4iMHIKfpMrFR9D
> 04Eo0H+fRSqBWjVXz+JUnT9H4IktGh1GHTTACzZUe70oEA8E3rFxRRhFgOyNtZgU
> F4rfVXvuP7gd/B6r9AVJ89sB7ackFbqMXMcBzcXk/gqXG+kizzR0GBfdQJC7wCoN
> D9ST01tB8a/O3l2rOCxFrZA9ish9lXaIZ/jdCyw6C+BIhL/E5+cSAgX/dxsDTSco
> WlbteB2Upkp/w/KWauzyzXGkbWVZSBmUew1IQrk6FPNVR+kfRyr0o9fg7QQbcnYd
> rLSNW/ZJ9Jec5JNzPNSXrpA0jwzwTSdflbCUo4GWpiZKzagEZodisLNTn+8F4cBE
> 36uflxO0mMDnO4wxnQk/34rFfaRzOSKtEzsJPEw/KKGwWfjWLfI1Vz7lgkS5H/up
> 3lT36LABSnOWoOpkBDPhX3wheQu11FDwnv+dXqf2doDNsRwBJOC03y3/VxXdJlsZ
> hhuke+DxnFbv1LoHl5A3vZNqPS7RDbxMUz3O1511kKrnjxuNA+rJED+FpAfuNtHF
> Ger5Yb3TQ5OCby/gFMnONjWu2Pg6siipPyM0PM7Sz1Rn9hiWUGHw6xDV4bDwTAOs
> liTd04aMlII2NGRch80Sn1LKEWoLW84qNW+j6lEFXSIXvywmtX+6PJzPbabn7Sgw
> fIHtT9rIzITbLqka5yuU
> =3JHG

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Mar 2015 11:47:18 -0700

On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams <
[email-masked]> wrote:

> According to the current stunbis draft, it is still a requirement to keep
> your request down below 548 bytes for IPv4 if you don't know the real MTU
> and your request is not directly associated with MTU discovery. The value
> for the ORIGIN attribute could consume nearly half of that and the 3rd
> party auth token could consume nearly half of the remainder. If we don't
> think that 548 bytes is a reasonable requirement for the unknown MTU case,
> then the requirement should be removed from the spec.
>

The ORIGIN will only be that large in extreme, likely pathological cases.
Based on a median DNS name length of 12 bytes, the median median ORIGIN
value is 24 bytes, including attribute header. (
http://datagenetics.com/blog/march22012/)

> the IPv4 minimum. I don't think this it's common, but I unfortunately don't
> have numbers to quantify the scope of the problem so my assessment is based
> on a faint memory from a few years ago where I had to allow packet
> fragmentation in these cases in order to avoid dropping the packets
> entirely. I would rather send fragments than drop the whole packet, at
> least for the applications that I support today, and again, I believe the
> issue to be rare.
>

Recall that the IPv6 minimum is 1280 bytes, so hopefully by the time we
have enough attributes for this to be a real-world problem this 548 byte
limit will have been increased substantially.

>
> As per my previous e-mail, I'm more concerned about control messages than
> I am about data messages, since I think there's less flexibility around the
> message size. If the control message gets fragmented, on some paths it just
> won't get through. I would be happy enough with an solution for control
> messages, but even that I don't consider to be critical at the moment.
>

I agree, and I think that taking on a complex solution like SCTP to solve
what appears to be a non-critical problem is not a wise path.

---

From: Brandon Williams <[email-masked]>
Date: Fri, 13 Mar 2015 16:22:08 -0400

I think we're pretty much on the same page on this one. I'm just 
exploring whether the current requirement in the text is a reasonable 
approach to the pathological case. Is it better to do what the current 
text requires (drop the packet)? Or is it better to relax the wording in 
recognition of the fact that the problem case is pathological and that a 
fragmented packet is more likely to get through than a dropped packet? I 
would rather relax the requirement than do a bunch of work, though I'd 
be willing to do a little work if we come up with a low impact fix.

--Brandon

PS: Really? Hopefully we can rely on IPv6 deployment? :-)

On 03/13/2015 02:47 PM, Justin Uberti wrote:
>
>
> On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     keep your request down below 548 bytes for IPv4 if you don't know
>     the real MTU and your request is not directly associated with MTU
>     discovery. The value for the ORIGIN attribute could consume nearly
>     half of that and the 3rd party auth token could consume nearly half
>     of the remainder. If we don't think that 548 bytes is a reasonable
>     requirement for the unknown MTU case, then the requirement should be
>     removed from the spec.
>
>
> The ORIGIN will only be that large in extreme, likely pathological
> cases. Based on a median DNS name length of 12 bytes, the median median
> ORIGIN value is 24 bytes, including attribute header.
> (http://datagenetics.com/blog/march22012/)
>
>
>     Regarding Justin's question about who is being kept awake by this
>     ... I know that small MTUs occur in some parts of the Internet, even
>     as low as the IPv4 minimum. I don't think this it's common, but I
>     unfortunately don't have numbers to quantify the scope of the
>     problem so my assessment is based on a faint memory from a few years
>     ago where I had to allow packet fragmentation in these cases in
>     order to avoid dropping the packets entirely. I would rather send
>     fragments than drop the whole packet, at least for the applications
>     that I support today, and again, I believe the issue to be rare.
>
>
>     than I am about data messages, since I think there's less
>     flexibility around the message size. If the control message gets
>     fragmented, on some paths it just won't get through. I would be
>     happy enough with an solution for control messages, but even that I
>     don't consider to be critical at the moment.
>
>
> I agree, and I think that taking on a complex solution like SCTP to
> solve what appears to be a non-critical problem is not a wise path.
>
>
>     --Brandon
>
>
>         On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         _________________________________________________
>         tram mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>     --

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 14 Mar 2015 18:48:01 -0700

It would be tempting just to add the 'native' SCTP support to STUN,
for the sake of efficient data delivery and easy implementation, but
it may contradict the original STUN intention - the NAT traversal aid.

On Fri, Mar 13, 2015 at 1:22 PM, Brandon Williams
<[email-masked]> wrote:
> I think we're pretty much on the same page on this one. I'm just exploring
> whether the current requirement in the text is a reasonable approach to the
> pathological case. Is it better to do what the current text requires (drop
> the packet)? Or is it better to relax the wording in recognition of the fact
> that the problem case is pathological and that a fragmented packet is more
> likely to get through than a dropped packet? I would rather relax the
> requirement than do a bunch of work, though I'd be willing to do a little
> work if we come up with a low impact fix.
>
> --Brandon
>