DASH Behavioral Model WG, 2 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG 20220602 (June 2, 2022)

Description

June 2, 2022

A

B

Okay, now it started.

B

Okay, yeah so hi everyone. um Today we will have our behavioral model session uh without christina. I will be uh in her stead um so for today what we have is. I would like to go over as usual. uh Our items in the project in the github also there was um there was an email by james.

B

um So we'll probably uh start with uh with what uh james had to uh had to say for this meeting and then follow up with the usual uh review of the of the assigned items yeah so james, would you like to start.

B

Oh sorry, john, not james, sorry, james from the uh from the previous meeting john.

C

uh Yeah I mean, I think, on the last call. I don't think you were on it marion, but um I sort of brought up this issue that um I had done.

C

Some experimenting on azure and it appeared to me, like the connection tracking behavior, was like a little bit different than um what we have planned for dash, um and I just wanted to you know make it known that, like uh that, that that was the case, and I think gerald said um you know that absolutely like the intention is that we can do the exact behavior that's being done today in azure.

C

He said, although some behaviors may be debatable and we can have the debate. So I he just asked me if I would send my notes, um and so that's what the email was about. It was just kind of sending the notes about the behaviors that I observed on azure for connection tracking.

B

Yes, so now the question is any of the differences desired to be taken taken back into the behavioral model,.

C

uh Yeah, I mean, I think uh I think we need yeah.

C

I mean I think, if it's, if it's our intention, that the behavioral model um you know match the requirements in those behaviors or requirements, then uh yeah, I think we need to, um although I don't think it like necessarily like changes a lot of what's already planned like I think we have a connection tracking logic, that's planned and it's based on the open, contrail logic, and I think these behaviors are kind of like sort of in addition to those they're not like uh completely different from those um so like.

C

I think it could be done in phases um but uh um yeah. I think that we would want to get the correct behaviors uh in the model.

B

So let me bring up the email.

D

D

B

Okay, so here is the summary: um we have two cases being at um across v-net traffic and uh intravenous traffic. um So within those we have you udp tcp for uh udp. um Let's start, let's start with udp. So if the, if everything, uh if we apply uh the corresponding policies for allowed, not allowed uh ports, this uh will be observed if the packet is first sent on the loud destination port and the response is sent on the deny destination board, the response is received right. um So how is that different from our behavioral models?.

C

Oh, I think the udp is like pretty much like what we would have expected. uh The only.

B

C

The only thing that I observed here is that uh it it looks like the time out from the connection table is five minutes. Okay, so that's just like a piece of information uh is that it's just a five minute idle timeout, once the you know, connection is established or udp connection is established.

B

Right but shouldn't the timeout be configurable.

C

um It probably should be, and and uh and I think that there was discussions in the past about um uh like it- could be configurable- it can come from the route entry. There's like all different ways that the timeout might you know um uh be flexible, but I'm just saying this is what I observed. um So it was really like with tcp, where I saw um I saw some.

C

You know more detailed kind of uh behavior.

B

So yeah about tcp, uh the bulk of your explanation is about timers and their values, but regarding the behavior of what is yeah, I'm.

D

B

How we can define what is the difference between behavior, you observed and behavior that we are right now have.

C

Okay, so there are a couple of things um one has to do with like you're right, like when you're in the sort of sin handshake um it's a five second timer when you're in the established state, uh it's a um five minute timer and again these could be configurable and then, when you're, in the fin, when, when you're in the fin handshake, you know the timeout is still five minutes except like when you get that final ack, um the it appears like the connection, is removed like as quickly as possible, but I actually observe that some packets can sort of get through after that final act, um so, like all of that, like is like fairly consistent with like with what we have already planned.

C

um However, like I did observe that um sequence number tracking on both the sins, the sin handshake and the fin handshaking on the fin handshake, is um like uh I'm absolutely certain that it's being done uh today, that if you don't have the correct uh acknowledgement numbers like if you just did the simple sin, synack ack and and said. Oh, that's good enough for the connection to be established.

C

um That's not what how it behaves today like today. Those uh acknowledgments have to be for the correct sequence numbers um so, but.

B

We also have planned for uh sequence, number tracking as well.

C

We have on both the sins and the fins.

B

C

It's in there, okay, so here's where I saw um maybe the most difference is um when you're, when you have an established connection uh or even like it's not even established, but there's a connection in the connection table uh in a new sin. Comes that would match that connection.

C

uh In one case, if the sin is like allowed based on the acl, then it's as if you're just starting brand new on that connection, uh like you go back to the state of like trying to of the five second timeout and the sin handshake.

C

Okay, so you know this is like a case that, like I don't think, is handled in the uh code that we have today.

C

um You know the the open control code, but it's a case that I think we have to handle, which is there's a connection in the connection table and a sin comes in like what do you do and uh in in in? If, if the sin is allowed um it it appears as if, as if um you know the connection just like starts back it's at its initial state, which kind of makes sense if the sin is not allowed by the acl.

C

It looks like the connections like completely removed um like like, if you send a sin in the like non-allowed direction like it at that point like any packets, you send, uh will will black hole so it it appears as if, like a sin in the non-allowed direction, just has the effect of removing the connection from the from the connection table so or the desired behavior.

C

That's what I see on azure and it's probably the desired behavior. I see right um so I think, like that's a behavior, that we would want to try to put into the behavioral model and then the other behavior that I saw had to do with like reset packets and it looked like if there's a reset packet. It looks like to me. The behavior looks like the timer just gets shortened to five seconds, but any packets are allowed in both directions and and if those packets are sent in either direction.

C

The timer, like continues to extend for like the five seconds, so you know after a reset, you could keep that connection open as long as there's packets within five seconds, um and so those are the behaviors that that I saw um so like. I think, um like you, said marion. It's mostly about the timers, but also the sin and reset cases, maybe like a little bit.

B

Yeah those two uh-huh.

C

Yeah, those two are.

B

C

Yeah and then there was this observation about like when you're in the same v-net um and what I observed when you're in the same v-net is that the udp behavior is exactly the same, but the tcp behavior seems completely stateless. um I don't I was had. I had was unable to show like any kind of stateful behavior within the same v-net.

C

Basically, what would happen is any tcp packet would be allowed, regardless of your security group, so long as it wasn't a syn packet, and if it was a syn packet, then it looked like the syn packet followed, the you know acl, but like none of the other packets followed the acl and they were I, they couldn't detect any kind of timers or anything. So I suspect that, like um on azure today for packets that are on the same v-net, they made some kind of a implementation trade-off.

C

Scale trade-off performance trade-off to loosen the security of tcp connections in the same within the same v-net.

C

I'm guessing- and I think gerald would have to speak to this, or some of the engineers from microsoft would have to speak to this. That this is probably not like the desired behavior, but just something that they uh did uh to simplify uh or improve the performance of their implementation.

B

Yeah so for the last point to be actually reflected in the behavioral model: acls permit deny rules, don't have a notion of the unit. They only look at the eni, so there should be someone who actually knows which enis are in the same v-net and then so it could be either achieved through a control plane that actually tracks all of that and does not deploy rules within the unit or does not enforce the rules within the unit so yeah it's.

B

If we would want to explicitly do that, it would require us to redefine how the acl rule looks like.

C

B

Yeah, so that's we can leave it as an open question, because if it's purely a performance optimization, I don't think it has to be incorporated into behavioral into behavioral model.

C

B

C

I don't even think it has to be incorporated into the implementations right. I think this is just like. Maybe you know like a compromise that was made uh uh by microsoft, but it would be nice for them to kind of confirm that.

B

B

um Okay, so uh from what I understand, we have two new items that we would want at least two new items that we would want to put in the backlog, first, one being uh behavior of uh connection tracking with regards to sin for the connection that is already open.

B

Yes, number two is actually having a timer after reset.

C

B

Different timer.

C

Yeah yeah yeah.

B

Or anything else you can derive from that.

C

um No and just the confirmation that uh that sequence number tracking is, uh is, uh you know, being used.

D

All the time well established or just for finns.

C

For sins and finns, so like uh there's a different timer before you get to the established state, there's a five second timer, and then it goes to a five minute timer once you're in the established state and uh andy. I you you can't get into that five minute, timer state, unless you use the the correct acknowledgement numbers to match the sequence numbers of the sins. So it's kind of like a like proof that uh that the current implementation, uh you know, uh depends on the sequence, number tracking.

D

Did you did you do any tests to see whether there was a window during establish after established on data? You know data packets in the establish phase, or is it just the synonym fin that were checked.

C

Yeah, I didn't check to see whether there's like uh window checking. You know there there is. You know. I know that some connection tracking implementations do window. Checking in the established phase like you have to be within, you know the current window. I didn't do any testing of that to see. If that's uh what, if that's being done, um I I just tested to see if it was tracking uh in order to transition to the to the states.

C

A

Yeah, if we some a little bit more analysis, maybe needed uh to see whether we need to track the sequence numbers which is very expensive.

A

If there is any other means at all, to identify the flow and the corresponding action in in the you know, the rst or fin state and after, uh if there's any other means to track that, rather than sequence number. If we can explore that that'd be great.

C

So uh I could tell you by like my interpretation of the rfcs uh there's not um you know that uh that, like the only way to be certain, for example, that you're that you're at the last ack of a connection is to make sure that the sequence number matches the fin um or you know the fin plus one or you know the fin plus the data length of the fin packet. So um you know to the rfc.

C

I don't know of any other way um to be certain that uh you know that it's the final fin or or on the sins, like I don't know of any other way to know that you know you're now in the established state. um So so uh you know you can you can maybe lose. You know, do something looser than that.

C

But it's uh you know it's. It's sort of outside of um anything that the rfc.

C

A

Okay, um we had done some analysis and there was something that we had identified, but uh I'm drawing from blank on that. So I will uh get that uh get back to you on that john offline and then we can discuss it. If that's a possible method or not.

C

um I mean I'm perfectly happy doing sequence number tracking so, like I I and I think that that's how it should work. um If that's something that's like too costly for you to do in your architecture, then I think it's a matter of whether it's acceptable to the customer um uh you know or if whether it's like, whether dash should define like uh options to sort of uh allow something looser.

A

Right right, yeah, if dash, can allow two ways to do this. One would be sequence number. Otherwise, you know uh another way so would like to discuss that.

C

Right but again, but like even if dash allowed two ways to do it. Ultimately, the customer would decide whether the way you're doing it is acceptable to them.

A

B

Okay, so uh next week we will revisit the backlog. I will prepare uh items that we found in a recent month or two that need to be added uh to the behavioral model.

B

So now, let's go over the current status of things so items in progress. We have.

B

Connection tracking in the simulator, so we are proposing uh slight changes to the pna architecture to um to accommodate for the use case uh of dash. The pull request was submitted.

B

We hope it will be accepted in a week or so after that we have all of the underlying implementation in the uh in the bmv2 pretty much ready, so it will be submitted when, when the pna, when the pna proposal is taken in so that's the last thing we are waiting for and then uh before runtime layer, uh translation to the uh from sai. This one was blocked by ipv4 ipv6 support.

B

Now that that one is merged I am, I am doing merge to my branch and this will be.

B

This will be available probably this week the final version of the pull request. I will resolve all the conflicts and we will have this along with the with the initial test.

B

Then we have another two items that are almost complete uh number one being a udp support waiting for test infrastructure. um So I think this one will be unblocked after I merge mine.

B

Another one support for list match type.

B

So kasim are you with us? Can you update what's but still.

E

Yeah, so on that we have been able to complete the development, and we are just waiting, we're waiting for you to grant access to the repo so that we can open the vr.

B

Wait repository exactly.

E

uh The bmw wrapper the bnb project that you, uh your fork.

B

Oh yeah, that's a good point, um so I will take it with christina. I'm not sure we need to keep it uh in the fork under my account. Maybe we should actually fork game v2 uh under azure, which christina will help me do and then you uh everyone will. Everyone from this group will be granted access so okay understand. So this one is actually let's say that it is blocked, and let me.

B

uh Bmv to fork.

B

Okay, so I will deal with that together with christina, we will have a public fork that you will have an access to and then you can publish your changes there.

E

B

Thank you um yeah, so that is, I think that is it. As I said, all of the backlog and unassigned items, we will revisit them on the next session. We have. uh We have a few more together with what what uh john pointed out in his work. um So please uh wait for next week to get an update on that and.

C

Yeah, hey marion, just one comment on that like it would actually be really useful if, if like microsoft, could like formalize, you know some of these behaviors, um I mean we like you know, I think we'll have to add them to the backlog and everything but, like um uh you know, we're sort of reverse engineering to come up with the behaviors like it would be much better if it were just direct like these are the expected behaviors.

B

uh That's true, I agree. However, probably there will be a problem with that, because uh sometimes well, actually, what we're trying to do with behavioral model is to formalize all of these behaviors. So it's kind of the checking and the neck problem yeah, but yeah. We can of course, ask microsoft to to provide anything at least on what we found and verify that maybe there is something else that we are not aware of, but from what I feel is that we discover those as we go.

C

D

I'm glad you're doing this work, john, because it, I suspect we can ask them for requirements all day long and it's just like the d. When you get down in the level of detail like this, most people just don't have in the top of their head, and so they won't bring it up unless asked. I think right, yeah.

C

B

Okay, good uh anything else, uh anyone wanted to talk about.

F

Another quick question: um do you guys think that all this information- and this now put in email should be going in some kind of documentation, um at least in them? You can do temporarily, so we can have it for a place where people can go find information, or it's too soon to talk about documentation.

F

What do you think, john or marion? What do you think.

B

I think it's all about if anyone is willing to do the work.

F

Well, I'm working on documentation with christina. If there is so, but I don't have the knowledge of the details, but if you guys think that would be appropriate, we do have some um some documentation about, uh ha but I'm not sure that's covering now this revolution and this search that is happening right now.

F

Because, really frankly, I did, I was working talking with the michael sigmund and he was saying would be possible to capture uh what is happening now in aha. So we can.

F

uh We can have a place where we can find out if we miss an email or whatever.

F

Just something to think about: that's, let's put this way, so if we can do the attacking up, if we want to do that- and I can talk with christina- also she's- not she's on vacation now, but I can talk for.

F

Just an observation.

B

So is it specifically for aha or behavioral model as well.

F

So yeah, that's uh that's a good point because it seems the two things somehow. Obviously there is an overlap. Obviously they will, uh you know converge sometime, but we can keep them separate for now and then we see how they they evolve. At least we have something written down, so people can look at.

F

Let's think about mary, we don't have to decide right now. I just want to make you aware that some I was talking with michael yesterday just about it.

B

F

I wonder if, for the behavioral model, we shouldn't have only very high level documentation, because the idea is that all the details will be in the model itself if we also have documentation. That explains, for example, what we have discussed today, what jonas brought to our attention, then we will have always to keep the behavioral model and the documentation aligned and it becomes double work.

F

While I think once we have the model, that should be the single source of truth and we, we probably need to open a pr with the the new couple of items that marion was.

F

I'm sorry not pra.

F

An issue with with the two items that marion was was summarizing from john's email, but I wouldn't then document these same behaviors beyond having them in their behavioral model. Okay, I think I I agree with you. I think, if we have a if we have a place like an issue and github, that would be better they'll, be good too. So then they'll be fine.

B

Yeah so to mario's point I think, on on one hand, um behavioral model, the one that we are building in p4 is the single source of truth, but it answers the question of what uh what or how the system is supposed to behave. However, it does not always answer the question of why and that's the reason we have supplementing documentation to describe why exactly we are. The behavioral model is doing what we're doing.

F

Yeah yeah very good point yeah. I agree with you. Yes, yes, you said it very well when I said the high level documentation. Actually, that's that's what I meant yeah compliment: okay, okay, yeah. I think this is a very good point. It's true, because otherwise people will see what's in there and they will not know the story of why it's there and yeah okay. That makes sense so marion, I'm available. In fact, I will talk with christina, whatever is needed, then we can do something in documentation and.

B

B

So if there isn't anything else, I think we can wrap up for today give some time back to everyone.

F

Sounds good. Thank you guys, thanks maria thank you, bye-bye.

B

See you next week, bye.

E