[PATCH] gtphub collapsed patch (aka bomb)

historical

----- Original Message -----
> From: "Neels Hofmeyr" <nhofmeyr at sysmocom.de>
> To: "Andreas Schultz" <aschultz at tpip.net>
> Cc: openbsc at lists.osmocom.org
> Sent: Wednesday, November 4, 2015 11:47:07 PM
> Subject: Re: [PATCH] gtphub collapsed patch (aka bomb)

> On Wed, Nov 04, 2015 at 04:46:41PM +0100, Andreas Schultz wrote:
>> The specs say to send replies to the IP and port where the request
>> originated. The GSN control plan address is only to be used when we
>> want to send a request to the other side.
> 
> Goodness, really?
> 
>> * for each request, cache the source IP+Port and forward the reply back
>>   to that,
> 
> Let's consider IP address and port separately.
> 
> - IP address:
> 
> The only time when the sender IP *can* even differ is during Create PDP
> Context messages. The only question is, where does the response to a Create
> PDP Context Request go. All other cases are clear.
> (For Update, only the Response can have differing IP address, but that's
> already the reply.)

I think you are over complicating thinks.

Lets take this step by step.

The simplest case is a reply. It will *always* be sent to the source IP
and port of the request. The source of the response should be the destination
IP and port of the request the triggered the response. So, you basically
just reverse source and destination and be done.

The GSN arguments in the request do not change that.

The GSN arguments are only used when you have to send a request to the other
side after the initial request.  

So, for any new PDP context, the initial request from the SGNS will go
to the GGSN address that you AAA told you use. Any follow up request
will go to the IP that the GGSN told you to use.
If the GGSN needs to send a request to the SGSN it will use the IP
the GGSN told it to use.

Thinks get interesting when you look at the Echo requests. For our GGSN
implementation, I decided to only use the IP's from the GSN information
elements.

> And even there it doesn't really make sense to have different addresses:
> the Create PDP Context Response coming back from the GGSN is explicitly
> addressed to the TEI that was declared in the Request. Why then would it
> be sent to a different IP address than the one that was also declared in
> the Request, explicitly to negotiate that TEI for that IP address?

The reply will be sent back to the source in any case.

TEI's belong to the GSN IP's from the IE, not to the source IP.

> Like, for one more reply, the TEI belongs to the sender address, and just
> after that it belongs to the negotiated address?
> 
> If this is used in practice, can anyone illustrate for what situation it
> is useful to negotiate a PDP context where the sender differs from the
> negotiated Ctrl address? Load balancing for User, yes, but Ctrl??
> 
> In the user plane the entire ambiguity does not exist at all. Messages
> are sent to the address that was in the Create PDP Context request,
> period. So I actually assume the ctrl plane works the same.
> 
> OpenGGSN does actually reply to the same IP *and* port it received from,
> always. It also replies to the same IP address even if the IE's address in
> the Create Context Request differs. This may just disprove all my points.

For the reply, that is absolutely correct. What does it do with any follow
up request? Would it use the IP from the IE or the original source IP? 

>> >- Disallow mismatch of CTRL sender and address in CTRL IE.
>> 
>> Seems like the reasonable thing to do.
> 
> In that case, the SGSN sender address and the CTRL address in the Create
> PDP Context Request must be identical and all the awkwardness is cut out.
> And wouldn't work if someone tried to do that, of course. Does anyone?

I have played only with Cisco (CSR 1000v) and there you can't configure
the source IP to differ from the ctrl IP.

Andreas
> 
> 
> - Port:
> 
> Ports can differ all the time. Any port number can be used as sender to
> send to a standard port of a peer.
> 
> This becomes weird as soon as we're talking GTP packets that contain
> a nonzero destination TEI to send to.
> 
> Echos send no TEI (zero), but they also don't require any resolution or
> tracing of peers: just reply, done. They go back to where they came from:
>  29.060 10.1.2.2: "NOTE: The source IP address of the Echo Response
>  message shall be the same as the destination IP address of the Echo
>  Request message."
> To see this "NOTE"d as loudly makes me assume that Echo is an exception in
> that way.
> 
> If I'm sending a message for a specific TEI, sending it to a different
> port feels wrong. The TEI was negotiated as part of a Create PDP Context
> for an IP address, with no port information attached. The TEI hence, at
> least in my head, resolves to an IP address with the standard port. No
> matter if it's a request or a response. That was my first guess...
> 
> But again OpenGGSN always replies to the sender.
> 
> Say different ports are used, what is the scope for TEI, recovery and
> sequence number? Does an IP address share these across all its ports, or
> does each port have a separate set of TEIs?
> 
> In case two separate ports know about the same TEIs, how then is it a
> problem if replies only ever go back to the default port?
> 
> gtphub implementation wise, a known sequence number can be used to trace
> back to the sender port, and the TEI can then be ignored. Once an unknown
> sequence number arises, the TEI resolves to the default port.
> 
> Having to manage ports per request seems unneccessary, on top of all the
> TEI business. Is there a benefit? Load balancing is done on the IP address
> level already, right? Is this ever used in the field?
> 
> 
>> I'm still trying to understand some of the finer points of GTP myself.
> 
> If anyone can enlighten us with hard facts from the daily grunge of actual
> GTP usage, that would be appreciated :)
> 
> We could examine some traces and check...
> - whether sender addresses ever differ from PDP Context message IE
>  addresses, and where responses go.
> - whether port numbers are ever nonstandard,
>  - where responses go, and
>  - how TEIs and seq nrs seem to scope.
> 
> 
>> >I'm handling IPv4 and v6 transparently, BTW. The difference in the IE is only
>> >detectable from the IE length, as 7.7.32 doesn't include the GSN address' type
>> >field. Let's hope IPv8 will have the same length as IPv6 :P
>> 
>> Lets hope all peers you are talking to are on the same IP version. Mixing IPv4
>> and IPv6 peer will be fun (see the Alternative GGSN Address).
> 
> Hmm yes, I just noticed that, too. Shall this and shall that. According to
> spec, you can't run a v6 GSN without also supplying alternative v4
> addresses. I'll just let v6 tag along until it becomes relevant...
> 
> 
> Thanks again, this discussion helps a lot!
> 
> ~Neels