--------------------------------------------------------------------------- BTNS working group meeting minutes --------------------------------------------------------------------------- These are the minutes for the Better than nothing security (BTNS) working group meeting, held at IETF-67 on Wednesday, Mar 21, 2007, in beautiful Prague, Czech Republik. Thanks to the people who have implemented MP3 recording of the session on which these minutes are based. Chair: Julien Laganier (Love Hornquist Astrand excused) Responsible AD: Sam Hartman * Agenda Preliminaries - Chairs Core and Connection Latching - Nico Williams API - Michael Richardson & Miika Komu IKE Extensions - Michael Richardson * Action items - Chair to submit AS/PS to IESG for publication as Informational RFC - Chair to issue WG Last call on BTNS Core document after meeting - WG participants to read and comment connexion latching, API and IKE extensions documents * Narrative minutes for the session --------------------------------------------------------------------------- Status update (Chair) --------------------------------------------------------------------------- Missing couple of milestones, but chair confident that we can meet them soon. AS/PS to IESG after the meeting. Soon WGLC for core & connextion latching. Soon adopt API documents as WG items. --------------------------------------------------------------------------- Core BTNS (Nico Williams) --------------------------------------------------------------------------- Slide 2: Change since -01 ------------------------- There's only two changes. One was the changes made to the PAD SPD entries in the examples to remove inconsistencies that Steven Kent pointed out. It's done, Steve can confirm. I also reworded the bit about address accumulation. If you remember, we need PAD entries to reject BTNS peers if their traffic selectors for their child SAs could be asserted by non-BTNS peers. Better wording is to make two ordered passes over PAD, one at authentication time, one at chid SA authorization time. That's it for the changes. Slide 3: Status: Ready for WGLC ------------------------------- Status is I think it's ready for working group last call. Questions? I thought it was ready for working group last call modulo Steve comments, so Julien I would ask for working group last call. Actions: Chairs will issue WGLC. -------- --------------------------------------------------------------------------- Connexion Latching (Nicolas Williams) --------------------------------------------------------------------------- Slide 2: What ------------- Connexion latching, it's sort of... It's to IPsec as TCP is to IP. It protects packet flows coherently, not just packets. Kind of like TCP builds byte streams out of packets. Alternatively it's a way to build IPsec channels. It's needed because channel bindings needs IPsec channels. In addition there's a desire to protect against change in policy. Helps to address the problem where the PAD and SPD policy allows multiple hosts to claim address from the same networks Finally this is a fundation to IPsec APIs Questions: Slide 3: Why ------------ We need it because you know for things like channel binding, we need IPsec channels. In addition there is a desire to protect against a policy changing in such a way that it will compromise packet flows. Also, it helps to address the problem we discussed both in Montreal and I think in Vancouver, or wherever it was, two meetings before, where you know, the PAD has an SPD policy basically allowing multiple nodes to claim addresses from the same network making it possible to steal each other's packets. Finally, it's a foundation for IPsec APIs, and it's also sort of described in terms of ... IPsec APIs. Slide 4: How ------------ The idea is that when a connexion creation trigger occurs... in UDP you may still have something like a packet flow, but it's not a connexion, think of connected UDP sockets in BSD socket API... So what you do is that you figure out what the peer ID is, and what kind of SA protection, ESP, whatever, what are the algorithms, etc., and make sure that all subsequent packets for that packet flow are protected by similar SA. If you find packet from same packet flow which isn't protected, you drop. If you want to send packet but don't have an SA, you drop. On connexion tear down, you tear down the latch. Slide 5: How ------------ The draft sketches two implementation designs, you don't have to do it in either of these ways. In approach #1, you record latch in upper layer protocol TCB, communicate incoming/outgoing packet SA parameters between IPsec layer and ULP, effectively tags packets as they move up/down in the stack In datagram-oriented applications the latch would have to... Well, in datagram-oriented applications, if the user connected socket, UDP socket, they have to enforce latch. Then in approach #2, you record the latch in the PAD and SPD and enforce the latch at the IPsec policy layer. Slide 6: Approach #1: Intimate Interfaces ----------------------------------------- So approach #1 is the intimate interfaces, it effectively involves having interfaces between the ULP and IPsec, and you know, we need a mean to say, hey tell me how you protected this outgoing packet, and this incoming packet was protected like so, and protect this packets like so. Slide 7: Approach #2: PAD-based latching ---------------------------------------- PAD-based latching is a little more complicated, it basically requires ULP to create create template PAD entry. For listeners we create 3-tuple template PAD entry. For initiators we create 5-tuple PAD entry Packets that match a template PAD entry cause an actual PAD entry to be created. The child SA constraints are populated from the packet. The peer ID populated from the SA that protected the incoming packet. And on connection tear-down you have to remove the cloned PAD entry. Slide 8: Properties ------------------- Approach #1 works for connection-oriented and non-connection-oriented ULPs. For UDP applications can connect UDP sockets, or they can record and enforce the latch through ptokens, which is something we'll see in Michael's presentation, or sendmsg/recvmsg. The approach #2 also allows for UDP, but only in connected state. Approach #2 also needs a TIME_WAIT like state. This is because the tear-down of the flow and latch have to be atomic with respect to new flow triggers. The wait time is given by local latencies only, how long it takes for packets to move up and down in the stack. Slide 9: Properties ------------------- But of course approach #2 is very close to RFC4301 model and if you have a NIC that say provides ESP/AH/SPD offload but which don't provide a way to tag packets, then you need to do something like approach #2. Slide 10: APIs -------------- At it's simplest this is just the traditional connect()/accept() BSD socket-type APIs and they can work connection latching without the application even knowing. Slide 11: APIs -------------- But IPsec APIs can give applications much more power. Who am I really talking to, what is their IPsec ID, not their IP address but what is their certificate, or what IP did they assert. Specify/verify that a connection's QoP meet/meet. We can check whether the latch is ESP, AH, algorithms... We can do leap-of-faith if we know the peer public key, and so on. So you see this in Michael's and Miika's presentations and their I-Ds. Slide 12: BYPASS OR PROTECT --------------------------- Finally there's something that I don't know if it belongs to this draft or not. It's BYPASS or PROTECT. Basically for some things it would be nice if you could have the notion of optional IPsec protection so the example that I give there is BYPASS If you want to be able to leverage IPsec, you want to say hey if you can, give me IPsec, and give me channel bindings, and we'll do channel bindings with the RPCSEC_GESS layer. Well if you can't do IPsec.... If we can negotiate this use of IPsec, great, so I call this BYPASS OR PROTECT. In Approach #1 this is handled by the ULP or the application, you still need some sort of SPD entry that says BYPASS OR PROTECT and the application knows what to do. In Approach #2 this requires the same sort of things and some more. Slide 13: BYPASS OR PROTECT --------------------------- So in approach #1, the ULP and application is responsible. In approach #2, we need to have some sort of template SPD entry, and that works kind of like the template PAD entry that I described earlier. When a matching packet arrives, unprotected, clone a BYPASS entry for just that 5-tuple. When a matching packet arrives protected clone a PROTECT entry for just that 5-tuple. The ULP has to tear these down when the flows end. On outgoing flow initiating packets the application must tell the system what it wants really, and it must be able to do with IKE timeouts. So okay I'm not getting an IPsec protection, so I just close that socket. Slide 14: BYPASS OR PROTECT --------------------------- So this is the example I gave before. That's it. Questions: I should point out that there are implementation of connexion latching today, and some minimal set of APIs. If you use Solaris you can look at the man pages for ipsecconf(1M) that describes connexion latching and tells you that if you change policy your changes won't affect existing latching. And then the ipsec(7P) man page tells you what socket option you can use to request or check what algorithms are used, but you don't get to see what peer identities are used so it's a small primitive API. I think KAME also has an implementation although I'm not sure. Questions: ---------- Chair: Who read the draft? -> Two persons. Chair: Please read the draft and comment on the mailing list. --------------------------------------------------------------------------- C-Bindings for BTNS APIs (Miika Komu) --------------------------------------------------------------------------- Slide 1: -------- Hi everybody, My name is Miika Komu and I'll present work i did with Sasu Tarkoma, Nicolas Williams and Michael Richardson. Slide 2: What Problem Are We Solving? ------------------------------------- So the problem that we are solving in practice is how do we make application IPsec awarer. How can an application know that a connection is secured by IPsec? How can the application tell to use the BTNS extensions. How to do this using the C language with the socket API. Slide 3: Diagram ---------------- We are interested in two kind of applications, the ones that use only the IPsec API, and then application that also use TLS, GSS or SASL APIs. Slide 4: Relationship to GSS/SASL --------------------------------- So what's the difference then with these higher layer APIs, GSS and SASL. The fundamental difference is that they are not using socket descriptors. The IPsec API is tightly bound to socket descriptors, and can be used simultaneously with GSS and SASL. Slide 5: Policies ----------------- Here are the functions for handling policies. There are some accessors to create and get policies... Slide 6: Channel Bindings ------------------------- ... and the same for channel bindings. Slide 7: Changelog from 00 to 01 -------------------------------- And this is the changelog from 00 to 01... These are the old slides, I submitted new ones, but never mind. 00 only contained ideas, but now there's some concrete interfaces in the draft. Nico, Michael, Love and Julien have given me lots of feebdack. Slide 8: Todo list 1/3 ---------------------- Todo list is quite long, so anyway it means some more code examples, and definition of error values. Slide 9: Todo list 2/3 ---------------------- I'll fix the terminology in next version, the constants will be strings... Slide 10: Todo list 3/3 ----------------------- Comparison functions for attributes to see if one protection is stronger than another, but I am not sure it is needed. Then more attributes definitions, and also conversion fucntions so that we can get human readable. Also lot of editorial corrections. These were actually the minimal version of the slides, I submitted longer slides. Questions: ---------- Sam Hartman: You should submit slides you actually presented during the session. Please make sure you don't overwrite these with newest version. Chair: I'll send a link to the updated slides to the list, but proceedings will contained presented version. Chair: How many people read the draft? -> Not too many Sam Hartman: One thing would be to encourage reviewer to make sure that anything in this API is consistent with RFC4301. Michael Richardson: Sam when you say everything should be consistent with 4301, there are three interpretations I can take with that. Which is that a 4301 implementation, all 4301 implementation implement everything in here? Or that everything in here can be done by some subset of 4301? Or in fact does not contradict with 4301 but may in fact extend it so that strictly 4301 implementation may need to be extended to implement this specification? Sam: I propose that any... so first one, must not contradict 4301, that's clearly important that you know for example you should not be able to... so for example 4301 doesn't permit an implementation to... 4301 does not really have a concept of optional encryption like... I mean things like connexion latching, today I cannot say that it's okay for some people on application 1234 to use ESP and for some people it's okay not to use it. I can't express that. Michael: Right, that would be an extension. Sam: That would be an extension. Nico: But extensions are okay? Sam: No... Okay, Steve is actually going to argue that this is not an extension, Steve is going to argue that this is a fundamental change. So certainly no fundamental changes, and we can have debates about what they are, but I think Steve is going to be pretty firm on that one, that particular one. Another thing is that, it would be nice if there were no... I would say that extensions that are not covered by 4301 would be bad... for example 4301 ... like SPD selection functions, and so if you wanted ... that would be fine, if you wanted things that are beyond 4301 I don't think they should be specified here, they should be specified as part of another document. Things in 4301 should be sufficient to implement API. Nico: I don't know, why? Sam: I don't think... Michael Richardson: But the whole point of this whole effort is that people want to do things that they can't do with just 4301. The whole point is that we're trying to make applications that want to do things beyond that able to do things. So limited to what 4301 says you can do, which does not say anything about API, so we can't have an API with that argument. So clearly that's not what you mean. The biggest issue is how do you interface there, and actually Nico has addressed that in details in his draft on connexion latching, how do you implement things, and actually there's one version of how do you implement things that makes it much more difficult to do the things but it's possible to do that with BITW or BITS implementation using relatively stricts 4301 concepts, although they may need the PROTECT OR BYPASS concept to be able to cope with that. So with the additional, with the internet connexions to the upper layer protocols we actually don't need or want to really go through all of the 4301 mechanisms, we don't have to because we did a classification by virtue of the fact that, particurlarly in the downward direction, by virtue of the fact that we created the packet with knowledge of the SA we want to go in, and that's pretty much it , and we also know in the TCP sockets which SA specifically was supposed to be received on. So we actually don't need to go and look at what the actual values were and Steve Bellovin has argued that actually it's completely irrelevant what they are, what matters is the crypto check determining whether the packet should be accepted by TCP. To not check is an extension, but we don't need to say whether or not you go with that effort so some of the rules in the processing instructions can be implicitely skipped and there's some interesting advantages in doing that but functionally, the functions are still there because TCP rejects packets from non originating destinations anyway. So that's the question when you say, is it consistent with 4301, well we're saying that we get the same result if you implement it that way, but we're not saying we work forward identical. Sam: Steve, I am correct that you object as much as I think to the PROTECT OR BYPASS concept? Steve Kent: When we set up the working group initially we did had a long discussion on important features of providing BTNS functionality. An essential feature was to not undermine the access control functionality of an end system doing simultaneously BTNS and conventional IPsec protection, so I think the burden is on people writing these documents to explain how that is still satisfied, rather than you know picking an individual issue here, it's to show that when the thing is set-up, the criteria is still met. Nico: Ok. And I think nothing in connexion latching undermines access control. So connexion latching can be done without any API, sure. BYPASS OR PROTECT is not needed if you do connexion latching without any API. However there is a class of applications which today do one thing and which might do something different if they could use IPsec. They might be able to say "hey, can we get IPsec?" and if not let's do not IPsec. That's the only place where BYPASS OR PROTECT comes in. And that would be done using port selectors that narrow packet flows significantly only to these applications that know how to handle this. Therefore I think no access control feature of 4301 model would be violated. Sam: Ok what Steve said today is much broader that what he said last time. I think Steve... there is ... so ... I don't think that the API document should be defining extensions to IPsec, I think that those should be somewhere else and that the API document should be defining an API to use extensions that are defined elsewhere. I am asking for architectural cleanliness Nico: This particular extension is something that connexion latching... Sam: I am not talking about connexion latching. Nico: No, BYPASS OR PROTECT I guess? Sam: No, I'm talking about the API document. Nico: Ok, the API document does not specify extensions. Michael: Well if we continue, my talk will try to show another direction, and it will probably get more clear where we're going. We should actually have done the talks in the reverse order. Nico: Right because Michael's API is the abstract API, not the C API. Chair: So maybe Michael you present the abstract API now... Michael: Yes. --------------------------------------------------------------------------- BTNS API proposal overview (Michael Richardson) --------------------------------------------------------------------------- Actually I should but Bill Sommerfeld's name on these slides too. But I'm not so sure if he's still alive, I've heard he is but couldn't talk to him. Slide 1: Three objects ---------------------- Oh yeah, these are also not the last version. So, on Monday Nico convinced me to add this third bullet, on Tuesday he convinced me to remove it. So essentially we have two objects and we concluded that the third object was not a first class object but was rather an attribute of the second object. We have protection Token, that deals with the details of one session, so if you like you can link it to an IPsec SA. We don't really want to tell that the application knows too many details of that, but that's the kind of thing, they are specific to an SA, protection tokens have no scope outside of the process you're running in, don't expect to put them in a Jabber channel and have someone else knows what they mean or anything like that. So they're very very specific, they have some attributes, some of these attributes could be things like strength and key size and things like that. Absolutelly never the actual keys, they would never be revealled. And anyone who did that I think deserved to be slapped. Then we have identity tokens, identity tokens are... I take a protection token, you can get from that an identity token. An identity token somehow maps to something like a certificate or other type of things, and may have what we created what this crededntials token, and this is the notion that may tell you where to get your private key, specifically in the case where they might be offline, or in a kind of smartcard or something like that. Slide 2: Connected sockets -------------------------- So let's just talk about you how get things, and this maps a little bit to the details like the C-bindings that Miika has worked on. So let's talk first of a connected sockets, so TCP, SCTP, or UDP sockets that call connect(), so basically we're not going to change I/O operations basis. Initiator for these things is the end that calls connect(), and we suggest for simplicity and describing the whole situation that you also think of it as such because it called connect(), it also created the first packet, and therefore caused IKE to do something and create the IPsec SA. Clearly that connexion doesn't have to be here but it will make things much simpler for everyone to understand. The acceptor is the end that calls accept(), and therefore becomes the IKE responder, and it's the IKE responder before the accept() call terminates so this is important because the responder really doesn't know its policies until after it gots the connexion, and the initiator of course would like to express its policies before the connexion occurs, but it may actually not know the details until after it completes, ok? Slide 3: Use case #1 -------------------- So use case #1, call connect() as an initiator, and accept() as an acceptor, and you didn't say anything special, and you say okay get my protection token from the file descriptor that I got from this process, so in accept that's a brand new file descriptor connected. Then you say okay get my iToken from the pToken, and this tells me essentialy, from the cryptographic point of view, who I am connected to. And if I like I can take a channel binding out of that, feed it into my GSS API, connexion latching, do things like that, ah excuse me, into the channel binding and I'm pretty much set ok? This assumes that the reason why the system to setup an IPsec tunnel was determined by the system somehow, so there is PAD entry, an SPD entry that said, when you talk to this host or when you speak to this protocol or any number of various selectors that we have in the system, said I want to do IPsec for this connexion, so no contradiction no new things here, just IPsec occured for some reasons beyond the application's knowledge and the application now can find out that in fact it did happened. This case does not distinguish between the case where it might happened, like BYPASS OR PROTECT, we don't know the situation we don't know that there may ever be cases where it's not accepted. But if didn't go through, we didn't have IPsec, we'll find out at one of these two points that there was no IPsec there. Slide 4: Use case #2 -------------------- So use case 2 is initiator, so you said get me the identity of my remote guy bob with whom I wanted to talk to, and get a protection token, and this should be essentially use my default identity whatever that is, I'm not going to tell you, you figure out, you know, who I want to talk to, that's bob identity. At a high level that might be a DN, that might be a raw public key, that might be an IPsec address, or something else. At this level of the abstract API we're not really going to care about that. I have a file descriptor, I got it from my socket call, it's a newborn, I set my protection token on this. What does that mean at the bottom level? That means probably some kind of a template PAD entry goes into place, probably something that has everything relatively well specified except for the originating ports. Maybe it's a populate-from-packet... Sam: You mean SPD entry? Michael: Yeah I mean SPD entry, I'm sorry. And it calls connect(), and crypto happens. Acceptor is like use case 1, if you like... that call the connect call... Nico: It's actually a template PAD entry as I described in the connexion latching presentation, because we're saying we're trying to constrain the address in the selector for the child SA for this packet flow for what happened to a protected perr, and that happende in the back Sam: And in the SPD? Nico: And in the SPD, but specifically it happened in the PAD... Michael: That's why I wrote in my notes SPD/PAD, and I didn't really sort out what these things really are in my head, I just noted that I have a template that means the right thing. Emphasis that these are standard unpriviliged calls, there's some details as to what extent an unpriviliged application can override the system, that's to a system level setting to decide, that's well into the realm of local policy, and you should think about it, and take ... but I don't think this is a subject for standardization or really great discussion here, except to realize that's considerations that you will have to make. Sam: I disagree, I think that we actually do need needs to get in this space so that we can provide IPsec solutions for the protocols we standardize and people can understand how they interact with locally configured SPD entries, and that's something I talk a little bit about last week-end, and talked off-line to some people. Michael: So Sam, are you suggesting that we should have in our API a statement explaining under what circumstances an unpriviliged appplication may overrides a system policy? Sam: I am saying that use of IPsec 4301 should talk about how SPD entries from applications are combined with system SPD entries, and what ordering would be used. Not in your document, but in use IPsec 4301. Nico: But it is in IESG right now? Sam: No just use IPsec 4301. You said IPsec 4301... It's out of scope of your document Michael: I understand your concern and I agree there's a concern and if you feel there need to be a greater statement I would be doing that. Sam: I think it's out of scope of your document. Michael: Yes. Slide 5: Use case #3 -------------------- So this is initiator only, I say: I like to talk to Bob. And I say: By the way, on this multi-user system, my name is Alice (Francis or Julie). Furthermore, and this becomes different than in the other slide, somehow I have this magic PKCS11 session. Nico: It doesn't need to be PKCS11. Michael: Yeah, this is not the point, the point is that there's a real world example where you've logged into your desktop, your computer is remote but your crypto identity is actually local to you and the application can somehow access to it, and furthermore can tell the IKE how to talk to it. So that's the important part of it, that somehow this handle, it's like a file descriptor, that somehow you tell IKE use that identity, and the resaon why I say I'm Alice, that's because these are definitely the phase 1 ids that ared use in the parent SA. So now I can do the right thing. I get a protection token and I tell the system I want to use these things as part of it. I set the token on the file descriptor and call connect(). So then the identity and the credentials are determined by the application not the system. Slide 6: Use case #4 -------------------- This is on the other side, on the Bob side. Bob has said "I want to tell the guy I'm Bob", and on this socket when you respond you need to make sure that you set identity, so you set that on the file descriptor, we call accept, and afterwards you probably want to find out who connected to you, and do something. But of course you have to set your identity to respond with. Potentially there's an https problem here, where you can only have an identity per port 443 - IP address combination, because the crypto happens before the virtual host thing. There's no good solution to that, there were proposals some time ago to have the iniator say which responder they wanted to talk to. But in this case the issue is that they don't say I want to talk to Bob, I said I am Bob. I am unclear what happens. Maybe this is not a problem that we need to solve, just need to write the question. They connected to me they said they wanted to talk to Frank, but only Bob is listening. What does it connect to? are we allowed to have multiple listening on the same port number with different security associations? That's an interesting system question that you might ask. Sam: So, what is the purpose of Bob saying who he wants to be to accept? Michael: Well, listening to any application where there's a secondary data port like FTP, you may have a situation where control connection has Alice to Bob, and later on you open a data port for them to connect back again, so you're trying to express that on that port to listen on you don't want the system identity, but Bob's identity. Sam: Ok, but in the case where you are not the initiator... Nico: I have an answer, in practice this is odd because when somebody comes to you as a responder, they don't tell you right the way who they want, what selectors they're using. Michael: Right, but from an IKE point of view, you hope to discover the mismatch. Nico: Well but the only thing that really does is act as a fallback. And we could get rid of it because the application can always do the filtering itself. And we could also have a notification from IKE that said: Oh dude you really meant Bob. Sam: Actually I disagree, I think that's kind of the wrong way to deal with this. I think that what this is.. It serves two purposes, first of all, it says make this identity available, if people try to establish an IKE SA to Frances then let's do that. The second thing it does is it should if it turns out that you need to establish an SA in the reverse direction then it says who to use as your initiator identity. I don't think it makes sense to make this peer filter on one responder identity it already accepted. If you want that kind of filter, it should be on initiator side. And Initiator can do that and say : I want to talk to Bob. And if it can't get Bob, then that connect() fails. Slide 7: Unconnected sockets (datagrams) ---------------------------------------- The next discussion is for unconnected sockets. You should think of this a little bit as this is the interface between TCP connected systems and lower layers. Slide 8: Use case #5 -------------------- The protection, the people you're talking to can change on every packets. So you can't just get the data independently of the packet. You can't use read() or fread() calls to get this stuff out. You could get the identity out and protection token on every packet you receive, so somehow you have to get it out of the recvmsg() call, so I put it there but in reality it would come through ancillary data. So you get that each time, itoken, ptoken, and in this case the initiator identiy and credentail determined by the system. It's not clear for unconnected if you can really set who I am expecting to be before I connect to you. And you could do that again it would probably work. So you could set your Bob identity. Slide 9: Use case #6 -------------------- For the initiator you get protection token and you send the message with the protection token. Now that may be a template ptoken. We don't think that there's any guarantee that you could use the ancillary data cmsg as a value result parameter. So you put the ptoken in, we're not sure how to get the ptoken out again, the one that actually was used, the one that contains the parameter of the session that was actually created as that message was sent. Including non-templated PAD/SPD parts. So it's an open question how to do that for this. I think that a number of systems could just happily do it, but I don't think it's guaranteed by any spec we have. Again unprivileged calls. Slide 10: Similarities to GSSAPI -------------------------------- We intentionaly did this similar to GSSAPI. And in GSSAPI the ctoken has to be first class object because there's no other context to associate with, because GSSAPI just lives in whatever kind of bytestream. Use case 5 and 6 are not easily implemented for systems using connection-latching section 2.2 "Latching through PAD manipulations and extensions". If you are using "Intimate interfaces between ULPs and IPsec" this is really easy to do, I actually implemented it a year ago, for not actually for connected sockets, for unconnected sockets where you cannot use any kind of standard selectors because the host at the other end with the transport mode SA to .... The document that I wrote should become the abstract API, and Miika's document should become the C-bindings of the abstract API. This is fairly similar to the way GSSAPI did it. Nico told me to my surprise that the GSSAPI documents were actually standard track, not informational. We should ask the audience what do you think? Any objection to the approach? Sam: I think the abstract API presentation was very useful, we can solve issues with 4301, I think this is a very good model. I think it's not completely abstract... Michael: I wanted to say is that the only thing you get to is the socket, kernel is in charge of rest of the details. Sam: I think it's a very good thing. --------------------------------------------------------------------------- Wrap up (Chair) --------------------------------------------------------------------------- Last presentations on IKE extensions (2 slides) was skipped because we were overtime. Next step: - AS/PS to IESG after the meeting. - WGLC soon for Core. - Please read and commenst connexion latching then we WGLC it. - Please read API docs so that we can adopt them as WG items. - Please also read and comment short IKE extension draft. That's it. --------------------------------------------------------------------------- End of the meeting. ---------------------------------------------------------------------------