Re: [AVTCORE] Possible Erratta in RFC2326 relating to 'source' parameter.

[Magnus Westerlund <[e-mail]>]

Hi Julius,

the Source parameter is the source address of the RTP media stream. When
using RTCP it will also be the source address for RTCP. So, this
information should not be provided in a C->S Setup request. Only in the
S->C response when we are doing playback. As it is the servers address
from where it will send the media.

For RTP over UDP there is no way of knowing that the client does this
correctly and that the media path(s) are correctly established unless
the solution for NAT traversal in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/ is used.
Which do verify that there are RTSP agents with the agreed on
credentials at the peer end of the media paths.

I hope this answers your questions. If not can you provide more focused
questions.

Cheers

Magnus

On 2015-01-04 21:47, Julius Friedman wrote:
> Please find my previous message without the attachment which seems to
> have been the result of why it was not received.
> 
> --------------------
> 
> I have come across several entities which use the 'source' datum but it
> usually contains their own [IP] Address, I am not sure why giving
> another [IP] Address there would be useful since it would probably be
> routed anyway.
> 
> I just wanted to make sure I wasn't missing anything and you came up
> with a perfect answer so, Thank you !
> 
> I would like to also point out that it also is a security concern
> because it can allow a client to connect to another server and this just
> looks like part of the RTSP negotiation; 
> 
> I can then technically also use any Rtsp server to DOS another server by
> having it attempt to connect to that server to setup something repeatedly. 
> 
> Additionally the server @ 'source' has no way of knowing the client
> would even be connecting to it and the client may not even be allowed to.
> 
> This is the text verbatim:
> 
>    source:
>           If the source address for the stream is different than can be
>           derived from the RTSP endpoint address (the server in playback
>           or the client in recording), the source MAY be specified.
> 
> The SDP has been exchanged and would then contain the necessary information about connection information, the source is the 'EndPoint' [IP] Address / Port pair from which the 'Request' has been received, taking any other such notion of this would not be beneficial in any circumstance, including `proxying` because the proxy would handle 'EndPoint' negotiation and have it's own set of headers to support such.
> 
> Based on these concerns can `source` be amended to indicate it's only such and not defined for use in the 'RTP/AVP' profile?
> 
> It would also reduce some of the work in the latest draft which indicate concerns about this parameter.
> 
> .Since we are on the subject of the 'Transport' header I have another question 'ssrc' in the same parameter, I have written into the 'mmusic' group several times but for some reason they don't seem to be responding.
> 
> Can a client send his 'ssrc' to the server? 
>  - (Obviously he can but) Is this already legal with the current spec? 
>  - If so how can the server distinguish it's own `ssrc` in the response?
> (E.g. if the server doesn't want that client to use that `ssrc` for some
> reason)
> 
> Why would this need to be done? in situations where a client is joining
> a session where many participants may already be active (especially
> multicast) it would be beneficial to avoid early 'ssrc' collisions with
> one of those.
> 
> Yes the client can already do this by just waiting for the response to
> assign it's own `ssrc` but the response does not indicate the 'ssrc' of
> ALL participants only that of the media server, rtcp eventually sorts
> this out with a Goodbye and then a new ssrc but none the less I assume
> that saving that time and bandwidth and also having the option to assign
> both client and server ssrc would also have other benefits.
> 
> Moving back to the part about the peculiar punctuation.. I believe these
> peculiarities come from a notion that everything was text based.
> 
> The latest draft makes no changes at all to this besides defining more
> syntax.
> 
> Since the binary framing was apparently an after thought (based on
> information from the drafts which show interleaved data in a 'DATA' RTSP
> response) I think this was remnant from that in some way or at least
> that's the best I can possibly imagine.
> 
> Why the framing octet would also be listed as a 'safe' character is
> beyond me, there were several other characters / octets which definitely
> could have been used e.g. 0xC3 -> 0xFF.
> 
> The fact that the document makes so many statements about ease of
> parsing and then literally and figuratively destroy this concept with
> bad decisions such as the framing character as well as the interesting
> syntax for the markup.
> 
> I will past some of those here :
> 
> 
>       1.4 <https://tools.ietf.org/html/rfc2326#section-1.4> Protocol
>       Properties
> 
> 
> 
>    RTSP has the following properties:
> 
> ....
> 
>    Easy to parse:
>           RTSP can be parsed by standard HTTP or MIME parsers.
> 
> 
> 
> ...
> 
> 
> 
>     4 <https://tools.ietf.org/html/rfc2326#section-4> RTSP Message
> 
> 
> 
>    RTSP is a text-based protocol and uses the ISO 10646 character set in
>    UTF-8 encoding (RFC 2279 <https://tools.ietf.org/html/rfc2279> [21]). Lines are terminated by CRLF, but
>    receivers should be prepared to also interpret CR and LF by
>    themselves as line terminators.
> 
>      Text-based protocols make it easier to add optional parameters in a
>      self-describing manner. Since the number of parameters and the
>      frequency of commands is low, processing efficiency is not a
>      concern. Text-based protocols, if done carefully, also allow easy
>      implementation of research prototypes in scripting languages such
>      as Tcl, Visual Basic and Perl.
> 
>      The 10646 character set avoids tricky character set switching, but
>      is invisible to the application as long as US-ASCII is being used.
>      This is also the encoding used for RTCP. ISO 8859-1 translates
>      directly into Unicode with a high-order octet of zero. ISO 8859-1
>      characters with the most-significant bit set are represented as
>      1100001x 10xxxxxx. (See RFC 2279 <https://tools.ietf.org/html/rfc2279> [21])
> 
>    RTSP messages can be carried over any lower-layer transport protocol
>    that is 8-bit clean.
> 
>    Requests contain methods, the object the method is operating upon and
>    parameters to further describe the method. Methods are idempotent,
>    unless otherwise noted. Methods are also designed to require little
>    or no state maintenance at the media server.
> 
> 
> 
> This literally becomes a nightmare when you have to reconstruct TCP
> sequences.
> 
> I have attached a small 3MB zipped Wireshark capture which shows one
> such case of my dealing with this issue.
> 
> This is only exacerbated by the fact the document allows packets up to
> the maximum holding size in this mode AND specifies that packets with an
> unknown context must be skipped...
> 
> Skipped how? Skipped as in past their header, past their data? Can that
> text even be there?
> 
> We are talking about TCP and in such a case the data from a previous
> segment was already received by the receiver and contains only some of
> the data how would they skip data they have yet to receive? 
> 
> I will explain why this is a security issue, Since there is no sequence
> information in the binary header it must be trusted to contain valid
> length values. Without inspecting the latter octets one can make no such
> assumption about the type of binary data contained therein, especially
> if there is no context assigned.
> 
> This if I can get a single TCP packet into a stream I can very easily
> inject a lot of 'receive' space thus exponentially increasing my chances
> of getting another packet into the stream.
> 
> I think that there should at the very least be a correlation between
> 'Block-Size' and the frame size such that frame sizes MUST NOT ever be
> larger than that value if not already.
> 
> Furthermore I think that something needs to be done to specify how to
> deal with nuisances such as 'more / less bytes available than indicated
> in frame' especially when we also have 'Rtsp' messages which can be
> interleaved at the same time in between frames (which can contain "$").
> 
> So to re-iterate my understanding of how things are in toto I have an
> example I will outline below which is is a Rtsp Binary Interleaved
> sender who tells a Rtsp Binary Interleaved client there is a frame of
> 48344 bytes on channel 0.
> 
> The client received only 1328 bytes.
> 
> 47016 bytes remain.
> 
> The client starts to receive again.
> 
> At this point there should only be the rest of the data in the frame
> (47016 bytes)
> 
> This data will come over several MSS sized segments, during which time
> the socket may also be written to again (before the segment is
> transmitted to the client).
> 
> {
>     If the latter data happens to get to the receiver before the other
> portions of the segment we have TCP 're-ordering' based on the sequence
> number and may multiple ACK's for the early packets.
> 
>     If any data is missed we will have a re-transmission.
> 
>     The data being 'received' on the socket by the receiver coming from
> the server comes from the data portion of the tcp packet which now
> contains data from a previous segment.
> }
> 
> The sender is now committed to sending the additional bytes as indicated
> however if the sender stops sending this data or it's truncated it will
> never make to the receiver. The stack will never be able to re-assemble
> the packet and now framing sync is lost.
> 
> At this point ANY data consumed from the initial frame header and data
> which was received must ALSO be dis-guarded but there is NO WAY for the
> server to indicate this to the client... (This is why UDP is commonly
> used, you get what you get and you don't what you don't)
> 
> There are a lot of articles outlining why TCP and RTP don't get along
> mostly citing the overhead of re-transmissions so with Rtsp you think we
> would have attempted to solve this not make it worse with bad encapsulation.
> 
> Something needs to be done about this because it's also a security
> concern, e.g. if a client were to send a rtcp packet to the server which
> is very larger and contains no data he could attempt to exhaust the
> resources of that server (if they didn't monitor their rtcp bandwidth
> properly) or at least force a higher amount of traffic.
> 
> So, information needs to be clear that there is no such thing as a
> packet of less then 8 bytes under rtcp and 16 bytes under rtp. (Unless
> compression is being used; ROHC or otherwise)
> 
> The null packet or any packet under 16 bytes would used for 'spacing'
> not a 'unknown' context, especially when I can have 255 channels, what
> unknown context am I going to use then?
> 
> That is 4 octets for the `$` header, and the rest for the the packet
> header which can then be inspected to be the same version, payloadtype
> and ssrc as required by the client.
> 
> This prevents a client who may also send a "GET_PARAMETER" under
> interleaved transport with weird headers and a body to attempt underflow
> also which is something the current specification does nothing to
> protect against.
> 
> "GET_PARAMATER rtsp://someuri/ RTSP/1.0\r\nCSeq:1\r\nDate:
> xx:xx:xx\r\nContent-Length:24\r\n$UserAgent
> $009\r\n$\0\0\aRTSP/1.$\0\0\r\n\r\nDatawith$IsNotAGoodIdea!\0\0"
> 
> This would allow applications to still take note of when a large frame
> was seen but not be forced to act upon it and potentially lose data, and
> depending on their implementation allow remote code execution.
> 
> I urge the committee to seriously look into these issues as they can
> have a large impact.
> 
> https://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html
> 
> VLC seems protected against overflow after this but with some testing I
> have determined that not only VLC but other servers and clients are
> vulnerable to underflow this way as well making it both a server and
> client issue.
> 
> I have more notes in my implementation
> @ https://net7mma.codeplex.com/SourceControl/latest#Rtp/RtpClient.cs if
> your interested, it relates to one issue I saw where even though frame
> length was good other data in the packet was invalid such as the
> 'Extension' or the 'Length In Words Minus 1' or the ssrc etc.
> 
> Hopefully I didn't banter to much, it's rather late.
> 
> As for my other 'issues' / errata for RFC2435 has anything been
> determined on them?
> 
> What about the one for RFC3550, has anyone sat down to do the math on
> that one yet?
> 
> Thanks again for your time and response and have a Happy New Year if I
> don't hear back by then!
> 
> Sincerely,
> Julius Friedman
> 
> 
> On Sun, Jan 4, 2015 at 3:28 PM, Julius Friedman
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     This is a re-transmission of my previous response which didn't seem
>     to make it to the list...
> 
>     Is there any way to confirm if I am properly signed up?
> 
>     I have come across several entities which use the 'source' datum but
>     it usually contains their own [IP] Address, I am not sure why giving
>     another [IP] Address there would be useful since it would probably
>     be routed anyway.
> 
>     I just wanted to make sure I wasn't missing anything and you came up
>     with a perfect answer so, Thank you !
> 
>     I would like to also point out that it also is a security concern
>     because it can allow a client to connect to another server and this
>     just looks like part of the RTSP negotiation; 
> 
>     I can then technically also use any Rtsp server to DOS another
>     server by having it attempt to connect to that server to setup
>     something repeatedly. 
> 
>     Additionally the server @ 'source' has no way of knowing the client
>     would even be connecting to it and the client may not even be
>     allowed to.
> 
>     This is the text verbatim:
> 
>        source:
>               If the source address for the stream is different than can be
>               derived from the RTSP endpoint address (the server in playback
>               or the client in recording), the source MAY be specified.
> 
>     The SDP has been exchanged and would then contain the necessary information about connection information, the source is the 'EndPoint' [IP] Address / Port pair from which the 'Request' has been received, taking any other such notion of this would not be beneficial in any circumstance, including `proxying` because the proxy would handle 'EndPoint' negotiation and have it's own set of headers to support such.
> 
>     Based on these concerns can `source` be amended to indicate it's only such and not defined for use in the 'RTP/AVP' profile?
> 
>     It would also reduce some of the work in the latest draft which indicate concerns about this parameter.
> 
>     .Since we are on the subject of the 'Transport' header I have another question 'ssrc' in the same parameter, I have written into the 'mmusic' group several times but for some reason they don't seem to be responding.
> 
>     Can a client send his 'ssrc' to the server? 
>      - (Obviously he can but) Is this already legal with the current spec? 
>      - If so how can the server distinguish it's own `ssrc` in the
>     response? (E.g. if the server doesn't want that client to use that
>     `ssrc` for some reason)
> 
>     Why would this need to be done? in situations where a client is
>     joining a session where many participants may already be active
>     (especially multicast) it would be beneficial to avoid early 'ssrc'
>     collisions with one of those.
> 
>     Yes the client can already do this by just waiting for the response
>     to assign it's own `ssrc` but the response does not indicate the
>     'ssrc' of ALL participants only that of the media server, rtcp
>     eventually sorts this out with a Goodbye and then a new ssrc but
>     none the less I assume that saving that time and bandwidth and also
>     having the option to assign both client and server ssrc would also
>     have other benefits.
> 
>     Moving back to the part about the peculiar punctuation.. I believe
>     these peculiarities come from a notion that everything was text based.
> 
>     The latest draft makes no changes at all to this besides defining
>     more syntax.
> 
>     Since the binary framing was apparently an after thought (based on
>     information from the drafts which show interleaved data in a 'DATA'
>     RTSP response) I think this was remnant from that in some way or at
>     least that's the best I can possibly imagine.
> 
>     Why the framing octet would also be listed as a 'safe' character is
>     beyond me, there were several other characters / octets which
>     definitely could have been used e.g. 0xC3 -> 0xFF.
> 
>     The fact that the document makes so many statements about ease of
>     parsing and then literally and figuratively destroy this concept
>     with bad decisions such as the framing character as well as the
>     interesting syntax for the markup.
> 
>     I will past some of those here :
> 
> 
>           1.4 <https://tools.ietf.org/html/rfc2326#section-1.4> Protocol
>           Properties
> 
> 
> 
>        RTSP has the following properties:
> 
>     ....
> 
>        Easy to parse:
>               RTSP can be parsed by standard HTTP or MIME parsers.
> 
> 
> 
>     ...
> 
> 
> 
>         4 <https://tools.ietf.org/html/rfc2326#section-4> RTSP Message
> 
> 
> 
>        RTSP is a text-based protocol and uses the ISO 10646 character set in
>        UTF-8 encoding (RFC 2279 <https://tools.ietf.org/html/rfc2279> [21]). Lines are terminated by CRLF, but
>        receivers should be prepared to also interpret CR and LF by
>        themselves as line terminators.
> 
>          Text-based protocols make it easier to add optional parameters in a
>          self-describing manner. Since the number of parameters and the
>          frequency of commands is low, processing efficiency is not a
>          concern. Text-based protocols, if done carefully, also allow easy
>          implementation of research prototypes in scripting languages such
>          as Tcl, Visual Basic and Perl.
> 
>          The 10646 character set avoids tricky character set switching, but
>          is invisible to the application as long as US-ASCII is being used.
>          This is also the encoding used for RTCP. ISO 8859-1 translates
>          directly into Unicode with a high-order octet of zero. ISO 8859-1
>          characters with the most-significant bit set are represented as
>          1100001x 10xxxxxx. (See RFC 2279 <https://tools.ietf.org/html/rfc2279> [21])
> 
>        RTSP messages can be carried over any lower-layer transport protocol
>        that is 8-bit clean.
> 
>        Requests contain methods, the object the method is operating upon and
>        parameters to further describe the method. Methods are idempotent,
>        unless otherwise noted. Methods are also designed to require little
>        or no state maintenance at the media server.
> 
> 
> 
>     This literally becomes a nightmare when you have to reconstruct TCP
>     sequences.
> 
>     I have attached a small 3MB zipped Wireshark capture which shows one
>     such case of my dealing with this issue.
> 
>     This is only exacerbated by the fact the document allows packets up
>     to the maximum holding size in this mode AND specifies that packets
>     with an unknown context must be skipped...
> 
>     Skipped how? Skipped as in past their header, past their data? Can
>     that text even be there?
> 
>     We are talking about TCP and in such a case the data from a previous
>     segment was already received by the receiver and contains only some
>     of the data how would they skip data they have yet to receive? 
> 
>     I will explain why this is a security issue, Since there is no
>     sequence information in the binary header it must be trusted to
>     contain valid length values. Without inspecting the latter octets
>     one can make no such assumption about the type of binary data
>     contained therein, especially if there is no context assigned.
> 
>     This if I can get a single TCP packet into a stream I can very
>     easily inject a lot of 'receive' space thus exponentially increasing
>     my chances of getting another packet into the stream.
> 
>     I think that there should at the very least be a correlation between
>     'Block-Size' and the frame size such that frame sizes MUST NOT ever
>     be larger than that value if not already.
> 
>     Furthermore I think that something needs to be done to specify how
>     to deal with nuisances such as 'more / less bytes available than
>     indicated in frame' especially when we also have 'Rtsp' messages
>     which can be interleaved at the same time in between frames (which
>     can contain "$").
> 
>     So to re-iterate my understanding of how things are in toto I have
>     an example I will outline below which is is a Rtsp Binary
>     Interleaved sender who tells a Rtsp Binary Interleaved client there
>     is a frame of 48344 bytes on channel 0.
> 
>     The client received only 1328 bytes.
> 
>     47016 bytes remain.
> 
>     The client starts to receive again.
> 
>     At this point there should only be the rest of the data in the frame
>     (47016 bytes)
> 
>     This data will come over several MSS sized segments, during which
>     time the socket may also be written to again (before the segment is
>     transmitted to the client).
> 
>     {
>         If the latter data happens to get to the receiver before the
>     other portions of the segment we have TCP 're-ordering' based on the
>     sequence number and may multiple ACK's for the early packets.
> 
>         If any data is missed we will have a re-transmission.
> 
>         The data being 'received' on the socket by the receiver coming
>     from the server comes from the data portion of the tcp packet which
>     now contains data from a previous segment.
>     }
> 
>     The sender is now committed to sending the additional bytes as
>     indicated however if the sender stops sending this data or it's
>     truncated it will never make to the receiver. The stack will never
>     be able to re-assemble the packet and now framing sync is lost.
> 
>     At this point ANY data consumed from the initial frame header and
>     data which was received must ALSO be dis-guarded but there is NO WAY
>     for the server to indicate this to the client... (This is why UDP is
>     commonly used, you get what you get and you don't what you don't)
> 
>     There are a lot of articles outlining why TCP and RTP don't get
>     along mostly citing the overhead of re-transmissions so with Rtsp
>     you think we would have attempted to solve this not make it worse
>     with bad encapsulation.
> 
>     Something needs to be done about this because it's also a security
>     concern, e.g. if a client were to send a rtcp packet to the server
>     which is very larger and contains no data he could attempt to
>     exhaust the resources of that server (if they didn't monitor their
>     rtcp bandwidth properly) or at least force a higher amount of traffic.
> 
>     So, information needs to be clear that there is no such thing as a
>     packet of less then 8 bytes under rtcp and 16 bytes under rtp.
>     (Unless compression is being used; ROHC or otherwise)
> 
>     The null packet or any packet under 16 bytes would used for
>     'spacing' not a 'unknown' context, especially when I can have 255
>     channels, what unknown context am I going to use then?
> 
>     That is 4 octets for the `$` header, and the rest for the the packet
>     header which can then be inspected to be the same version,
>     payloadtype and ssrc as required by the client.
> 
>     This prevents a client who may also send a "GET_PARAMETER" under
>     interleaved transport with weird headers and a body to attempt
>     underflow also which is something the current specification does
>     nothing to protect against.
> 
>     "GET_PARAMATER rtsp://someuri/ RTSP/1.0\r\nCSeq:1\r\nDate:
>     xx:xx:xx\r\nContent-Length:24\r\n$UserAgent
>     $009\r\n$\0\0\aRTSP/1.$\0\0\r\n\r\nDatawith$IsNotAGoodIdea!\0\0"
> 
>     This would allow applications to still take note of when a large
>     frame was seen but not be forced to act upon it and potentially lose
>     data, and depending on their implementation allow remote code execution.
> 
>     I urge the committee to seriously look into these issues as they can
>     have a large impact.
> 
>     https://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html
> 
>     VLC seems protected against overflow after this but with some
>     testing I have determined that not only VLC but other servers and
>     clients are vulnerable to underflow this way as well making it both
>     a server and client issue.
> 
>     I have more notes in my implementation
>     @ https://net7mma.codeplex.com/SourceControl/latest#Rtp/RtpClient.cs
>     if your interested, it relates to one issue I saw where even though
>     frame length was good other data in the packet was invalid such as
>     the 'Extension' or the 'Length In Words Minus 1' or the ssrc etc.
> 
>     Hopefully I didn't banter to much, it's rather late.
> 
>     As for my other 'issues' / errata for RFC2435 has anything been
>     determined on them?
> 
>     What about the one for RFC3550, has anyone sat down to do the math
>     on that one yet?
> 
>     Thanks again for your time and response and have a Happy New Year if
>     I don't hear back by then!
> 
>     Sincerely,
>     Julius Friedman
> 
> 
> 
>     On Tue, Dec 30, 2014 at 3:33 PM, Dale R. Worley <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Julius Friedman <[e-mail]
>         <mailto:[e-mail]>> writes:
>         >  Transport           =    "Transport" ":"
>         >                             1\#transport-spec
> 
>         In a few places, RFC 2326 seems to use "\#" in place of "#".  There
>         doesn't seem to be any documentation for this.  There seems to
>         be other
>         peculiar punctuation as well, including "\$" and "$'$".
> 
>         > Since 'source' is not listed I don't know the syntax, I assumed it to
>         > be an "IPAddress" however the text sates "address" so I imagine if I
>         > found a 'source=1.2.3.4:1554 <http://1.2.3.4:1554>' that would be valid however
>         I want to
>         > make sure since there isn't any syntax specified in the RFC.
> 
>         It's not clear to me that there *is* a "source=" parameter for the
>         Transport header.  Yes, there is prose describing source as a
>         datum, but
>         there's no BNF for a corresponding parameter, and a quick search
>         doesn't
>         turn up any instance of "Transport:  ...source=..." in any RFC
>         or I-D.
> 
>         However, "source=" is shown in
>         http://heim.ifi.uio.no/~meccano/reflector/smallclient.html
> 
>         > Also I would wonder is there any restriction on specifying a port or
>         > address range also ? e.g. 'source=1.2.3.4/321202/2 <http://1.2.3.4/321202/2>'
> 
>         Well, I see "parameter = [...] ";" "destination" [ "=" address
>         ]", and
> 
>            address             =    host
> 
>            host      =   <A legal Internet host domain name of IP address
>                          (in dotted decimal form), as defined by Section 2.1
>                          of RFC 1123 \cite{rfc1123}>
> 
>         so it looks like <address> cannot specifiy an address range or a
>         port.
>         I'd expect the port to be specified by the "client_port" and
>         "server_port" parameters.
> 
>         (BTW, it looks to me like the first "of" in the definition of <host>
>         should be "or".)
> 
>         > I believe there was a similar issue with Rtp-Info headers which was
>         > fixed in 'biz' however this among other issues were not addressed and
>         > I am wondering if any other updates will be made to this RFC before
>         > 2.0 Draft is finalized.
> 
>         An RFC is never "updated", although it can be obsoleted by a
>         later RFC
>         that entirely replaces it.
> 
>         Dale
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------