We're going to have Fernando's going to be talking to us about flexible network operations
on network packet fields with NF tables.
All right, hello, everyone.
I'm Fernando, I'm a Linux kind of network engineer,
Susa, and recently I sent a new RFC to net feed
turn NF tables implementing a new NF tables expression,
which is the NFT math expression.
And here we are.
So a little bit of context.
Well, you know, IP tables and if tables a bit
integration, people is moving away.
But there are still some stuff that people can
do in NF tables, thankfully.
So we are trying to reduce that gap in features.
And one of the remaining features was the TTL increase,
the increase of TTL manipulation that is not just a plain set.
So how it works first in IP tables.
So in AP tables, usually you will just use the,
I get those extensions for TTL,
you will call it TTL increase, whatever number,
or TTL decrease.
And the best thing about this is that
well, only works for TTL.
It's not doesn't support any other packet field.
And that's in the IP tables model.
If we wanted to support, for example,
we would like to find a meta mark.
We will need to create a new extension to just handle that.
And therefore, it's a cumbersome,
because the maintainer's boundary of all that code,
and the complicated code will be,
will be to match.
So in essence, we came with the idea to have something flexible.
We really have the payload expression.
We have the meta expression.
So we thought instead of a set,
we could use the code to increase.
And it will, originally,
I will look something like that.
But I might say that this is the user space code,
which is not done yet,
because first we need to get in the kernel code.
But in my mind, the end result,
it would look like something like this.
So you will be able to specify the,
the header, I don't want to modify the protocol,
then the field, and then the operation.
And the code, increase and decrease,
a base report.
But we are open to implement any other mathematical operation
that makes sense,
and we have a new case for them.
And the good thing is that it will be flexible.
So as NF tables has an internal information machine,
and we have the registers,
and also one that we're going to spend a little bit later.
We are able to capture whatever data,
modify that data from the packet,
and insert it into this KB.
So the idea is that this expression,
we could use it everywhere,
so the same implementation could be used for payload,
which could be used for IP, UDP, DCP fields,
whatever protocol actually,
even not only header values,
but you could look into the data if needed.
And then also for other stuff like the meta values,
so the meta mark is the most relevant one here.
And yeah, there is something to the RFC right now.
We are in a B2,
and I have already, I have prepared already a V3,
that I'm glad to send soon,
and I hope I can get this marriage on the next cycle.
So I mentioned it before,
the NF tables register,
so what are they?
In essence, in NF tables,
it's an internal B2 machine to process the rules,
and we have some registers that act like shared memory
within the expressions,
or the NFT context.
So the packet field that can be copied to those registers,
then those registers value can be modified
by any other expression, in this case, for example,
the mathematical expression,
but we have already other expressions I do that,
for example, bitwise,
or byte order expressions.
And that that can be written back into the specific field of the packet.
So for the goal,
we want to reduce the application of goals,
so we plan obviously to use the existing expressions,
like payloads or mate expressions,
because also when you modify a header,
you need to recartulate the checksum,
and that requires some extra operations,
but we already have support for that.
So we can avoid implementing all of these in the mathematical expression,
and we can use the existing support.
And also, we already have the byte order,
especially to be able to change the byte order as needed
when manipulating the data,
depending on what kind of byte order is the data stored in the kernel.
So the byte code generated for use cases,
where we want to increase the TTL.
If we look something like this,
so in essence, what this is saying is,
well, it's defining the table,
it's defining the chain,
and then it says the first rule of the chain,
payload, expression,
it's going to load two bytes,
from the network header plus one byte of offset.
So we get to the TTL field,
and that data,
we are going to store it into the register number one.
And then, over that register,
we are going to apply the math expression,
which is going to say that we want to operate with a field
that is going to be eight leads.
And the reason why we are talking bits of math expression,
and not by it,
as we are doing in the payload,
is that we want to keep it flexible as possible.
So if in the future,
we are going to specify a packet field
that is two bits only,
you are able to do it,
and you don't need to do weird things.
And also,
we need to specify a bit mask,
because depending where the data is placed,
the data in the register could be placed
in the most significant byte,
or the less significant byte of the register.
So we need to specify that.
I must say that all of this,
is usually no handle by the user.
This is handled by the user space tool,
like NFT or faculty or whatever.
So this is kind of more internal than anything,
but currently it's the way we have to prove
the things are working.
And then, what it says,
the register one,
plus one,
and store it again in the register one.
And at the end,
we are going to call the payload right,
this is a expression,
so it's going to write the register one value,
the data,
into which is two bytes,
and then a worker header,
plus eight bytes of a byte,
and then it does some checks and recalculation.
So for the metadata,
for the metadata,
expression is even easier,
because we don't need to do any stuff
related to the checksum,
and it looks like metadata,
load the mark,
into a register,
we operate with a register,
this is a 32 bits field,
we do the same operation increase,
it could be decrease,
and then we set the value with whatever
is stored on the register.
Here we are already handling with all the flows,
so if you are already at the limit of the type,
it's not going to do anything,
and well,
you're not going to have any problem.
All right,
so enough checks,
let's do some demo,
I have prepared a demo,
where I'm going to increase the TTL,
because it's the most common use case,
and I'm going to explain what's happening.
So I have two VMs in the demo,
that are connected to each other directly,
so the packet is being stretched,
without any intermediate point,
the TTL therefore of a ping is not going to be reduced,
when it arrives to the end machine,
because there is no rotating in the middle,
and when we are going to do is to have
one NF table rule,
which is going to set the packet,
if the TTL is 31,
and one that is going to drop the packet,
if the TTL is 30.
So we will be able to see what happens,
when we are using the math expression,
and when we are not using the math expression,
and we will be able to see that the packets are being accepted,
or dropped in the other case.
So let me, this,
all right,
just a little right,
better, a bit better,
I can try to make it,
I will try like this,
I need to be worried about the formatting,
so,
all right.
So right now,
what's going to happen is on the left side,
I'm going to log in into the machine,
where we are going to configure the math expression,
so in the rule set that we have,
we have output a table with a chain in the output hook,
and there I'm using,
I'm going to run a programming C that I wrote,
because as I said,
the NFT code is,
you suspect code is not ready,
so I wrote a C program to test this with,
dealing with all the main language stuff,
and I have inserted the,
the math expression rule,
and now I'm going to run another C program to get the byte code,
because again,
well,
if you can see,
it's similar to the one that they show on the,
on the slides,
and now on the right side,
I'm going to log in,
and I'm going to show the rule set.
Okay,
so there,
what we have on the right side,
the formatting is a bit bad,
but what we have,
if the TTL is 31,
in the ICMP packet,
we are going to accept it,
and if the TTL is 30,
we are going to drop it.
So now we are going to ping that using
the option 30,
and as we are using the math expression on the output hook,
whatever we said,
the TTL,
we are going to increase it by one.
This is usually not obviously pretty useful,
but it's for the,
just for the testing.
So the packets are,
sorry,
isn't it very dangerous?
Yes,
so this is just for the testing,
usually you should do this only on the forward hook,
and to do transferings for wording,
but right now,
let's do this for testing.
Yeah,
so we have done the ping,
and it's going well.
Now we've finished the rule set,
so the math expression is gone,
so we are not increasing the TTL anymore.
Okay,
and now we ping,
and the packets are falling into the TTL 30 rule,
and therefore I've been dropped,
so the ping is not working,
because well,
the TTL is not being increased anymore.
So as you said,
yes,
it's very dangerous to do this,
the idea to use the TTL expression is,
the math expression for TTL,
is for forwarding only,
and well,
just to make a router,
do not reduce the TTL,
if you want to have some transparent process in the middle.
But yeah,
I just did this for simplicity,
and avoid having too many things,
because I need to make it short for the demo.
So that's it.
The idea about this is that we plan to be open
about what kind of use case,
do they use at half,
for operations,
and support them.
And that's it.
Thank you.
Very much.
Thank you.
In your architecture,
is it the user space code that is generating this code?
Sorry.
In your architecture,
is it the user space code that is generating
instructions for the virtual machine?
Yes.
So the user space is sending the learning messages,
configuring everything on kernel side.
That's how you understand it.
I mean, the actual code generation.
What do you mean, sorry?
You showed some examples of code.
This byte code.
Yeah, exactly.
Oh, yes.
This byte code is in a sense,
how the NF tables rules are turning out.
It is being generated on user space side.
Yes, I created a C program to generate this.
Because I think you have some use cases where you have
discontinuous or discontinuous speed fields.
I think the terms.
Yes.
And is this something that you are also looking at?
Yes.
We have data mine.
But the idea is that we are waiting for people to,
because this is quite new.
People was not expecting to be able to operate with whatever
field.
That's a new thing in the NF tables.
And we wanted to wait to hear
what they need to increase, what they need to operate with.
And therefore provide support for discontinuous fields.
But it's a mind.
And we are trying to make it flexible enough to support
those cases in the future.
You have tied to the presentation about some doing math.
Sorry.
You tied to the presentation about doing some math.
When I hear your math, I always reply for it.
Does it mean that you have implementation of four to
end, which inside it?
How do you do math?
How do you implement math?
Is it four to end, which inside or how do you do that?
So actually it's quite simple right now because we have some ways
in the kind of mathematical stuff.
I mean, not super complex, but we can divide.
You can multiply.
Are we running up?
No, that's my point.
No.
But you can always.
Yeah.
But I mean, that's usually it's better to implement
four machines and let's say it and do it.
Do any math after that.
It's flexible and scalable.
Thank you.
All right.
Any other questions?
Thank you.
Oh, is there one up?
Did you want the afternoon?
Yep.
I wonder about the syntax there.
I would have expected a wreck on the right-hand side of the assignment
operator in the math line.
So all these syntax, if you are an NFTable user, you're
kind of ignoring this kind of internal.
It's all the user space that you usually use when you say NFTable
translate that whatever generates a bytecode.
And this is kind of a representation of what
is actually happening in the background.
Because here, for example, you are not
specifying if you look at the syntax, which is the
syntax at the top is what you will use as an end user.
And here, you're not saying payload expression.
You're just specifying IP had a TTL field.
But NFTables translate that into low-level things.
Use this expression.
This kind of module with this specific values and
the bit mask and a lot of details that NFTables
resolve on its own so you don't need to do it.
Okay.
Thanks.
Thank you.
Thank you very much.
Thank you.