6 Nov
2015
6 Nov
'15
10:43 a.m.
----- Original Message -----
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
From: "Neels Hofmeyr"
<nhofmeyr(a)sysmocom.de>
To: "Andreas Schultz" <aschultz(a)tpip.net>
Cc: openbsc(a)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:
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.
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.) 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.
- 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?
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
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).