From Nicolas.Williams at sun.com Mon Apr 7 11:00:04 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 7 Apr 2008 13:00:04 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: References: <20080225093002.01ABB3A6CB2@core3.amsl.com> Message-ID: <20080407180003.GB16998@Sun.COM> On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote: > Hi, > > Here are my comments on the draft. I tried to sum up the exchange I had with > Nico. Thanks. My comments follow as well. > < Although it adds almost nothing to the introduction and it is mainly a > re-writing of the introduction, it might bring some clarification to the > paper and to the connection latching concept: Your proposed new intro text seems to do three things: summarize the IPsec architecture (RFC4301), restate part of the intro that's already there and, importantly, restates a constraint that is not clearly stated in the intro (though it is stated elsewhere). That constraint is this: that under no circumstance does connection latching cause persistent changes to IPsec policy databases. I don't think it's safe to try to summarize the IPsec architecture here, so I will not take that text, but I think it's crucial that sa So I will add text like this: > < The changes are requested from applications and not from the network > administrator, which means that the ULP must not systematically overwrite > the IPsec policies established by the network administrator. For example > policy requests must not survive to crash, must not establish lower security > as defined by the network administrator. One way not to survive to crash is > to disable any modification in the user land. > < > < This lead us to consider a new object that will define security rules with > specific characteristics : the Connection Latching Objects. > < > < This document defines : > < - What is a connection latching object (Section 2 Introduction). > < - The behavior of a latching object (that is to say its state machine > section 2.1). > < - The interface of the Latching object with key managers and ULP > (section 2.2). > < - Interaction between LD and traditional IPsec databases (section 4). to the intro. I will also add a sentence to the abstract (I'll also delete a redundant sentence from the abstract) to the same efffect: Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Additionally I'll add text to the security considerations section about this. Something like: Connection latching adds a new, non-persisting database to IPsec and new functionality to the IPsec key manager. Stripped of all optional features, connection latching is really about protecting established packet flows from SPD and SAD changes that are not consistent with what the application and/or ULP would like. This protection is achieved by tracking latched connections and synchronizing changes to the SPD and SAD with alerts to the ULPs that are responsible for affected latched connections. Excluding all optional features connection latching is simply a passive feature bolted to the side of the IPsec key manager. When a connection latch cannot be guaranteed the only action to be taken is to synchronously inform the affected ULPs and applications. Including all optional features connection latching also involves dynamic modifications to the "logical SPD," which do not persist across reboots nor past the lifetime of latched packet flows, and it also optionally involves IKEv2 CHILD SA narrowing. That connection latching state never persists beyond the lifetime of associated packet flows, nor across events which necessarily terminate such state (including reboots), derives from the fact that the very state of those packet flows is also non-persistent. We believe that this construction of connection latching achieves the desired goal -- protecting applications from dynamic IPsec policy or too permissive an IPsec policy -- without doing violence to the IPsec architecture. > < The considered model can be thus represented by the figure below: I like your ASCII art, but I'm going to modify it somewhat. Following our conversation I think we need to clearly delineate "kernel" and "user" mode execution, even though it's mostly irrelevant in a document like this one, because it'd relevant to most implementors; your figure almost does this. Also I think the ULP needs to be a box, as should be the key manager. And rather than refer to decorrelated and non-decorrelated SPD I'd rather speak of SPD and "logical SPD," where the latter is in the kernel. This last change is important because we want to demonstrate that connection latching, even with all OPTIONAL features, never modifies persistent IPsec policy. > < The ULP interfaces to the IPsec LD database are as follows: > --- > > The ULP interfaces to the IPsec PAD database are as follows: Good catch. I'll make it "The ULP interfaces to the key manager ..." > 648,659d584 > < The IPsec to ULP interfaces is as follows: > < > < o POP_MESSAGE(5-tuple, message) -> latch handle > < > < Pop up a message (code) to the ULP. Yes, I'd described the IPsec->ULP interface rather informally. I think we want something like: o INFORM(5-tuple, BREAK | SUSPEND) There's no return value for this function. > < The State diagram with functions can be represented by the figure below: > < [I removed mine] Er, could you send it again? I'll review your "Interaction between LD and other IPsec Databases" section next. Thanks! Nico -- From Nicolas.Williams at sun.com Mon Apr 7 12:38:11 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 7 Apr 2008 14:38:11 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080407180003.GB16998@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> Message-ID: <20080407193811.GK16998@Sun.COM> On Mon, Apr 07, 2008 at 01:00:04PM -0500, Nicolas Williams wrote: > On Fri, Mar 14, 2008 at 06:53:24AM +0100, Daniel Migault wrote: > > < The considered model can be thus represented by the figure below: > > I like your ASCII art, but I'm going to modify it somewhat. How about this (GIF version attached): +--------------------------------------------+ | +--------------+ | | |Administrator | | | |apps | | | +--------------+ | | ^ | | | | user mode | v | | +--------------+ +---------------+ | | |App | |IKEv2 | | | | | | +---+ +----+ | | | | | | |PAD| |SPD | | | | | | | +---+ +--^-+ | | | +--------------+ +-----------|---+ | | ^ | | +---|-------------------------------|--------+ user/kernel mode +---|-------------------------------|--------+ interface | v | | |+-------+ +----------------------|-------+| ||ULP | | IPsec key manager | || |+-------+ | +------v------+|| | ^ ^ | | Logical SPD ||| | | | | +-----------^-+|| | | | | +----------+ +-----+ | || kernel mode | | +-------->| Latch DB |<-->| SAD | | || | | | +----------+ +--^--+ | || | | +--------------------|------|--+| +-|-------------------------------v------v---+ | | IPsec Layer (ESP/AH) | | | | +-v------------------------------------------+ | IP Layer | +--------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: conn-latching-arch.gif Type: image/gif Size: 7967 bytes Desc: not available Url : http://mailman.postel.org/pipermail/anonsec/attachments/20080407/dcab6f47/conn-latching-arch.gif From Nicolas.Williams at sun.com Tue Apr 8 10:30:36 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Apr 2008 12:30:36 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080407180003.GB16998@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> Message-ID: <20080408173036.GS16998@Sun.COM> On Mon, Apr 07, 2008 at 01:00:04PM -0500, Nicolas Williams wrote: > > < The State diagram with functions can be represented by the figure below: > > < [I removed mine] > > Er, could you send it again? Never mind. I've written one: | CREATE_LISTENER_LATCH() | | v +--------+ / |LISTENER|-------+ +--------+ | / | / | + | | v v +-----------+ +------|ESTABLISHED|<-------+ | +-----------+ | | | v | | +------+ | | +---------+ |BROKEN| | +----->|SUSPENDED| +------+ | +---------+ | | | | | v | +------+ | +-------->|CLOSED|<-------------+ +------+ > I'll review your "Interaction between LD and other IPsec Databases" > section next. I think your sections 4. and 4.1 mostly restate what a lot of the draft already says, but section 4.2 inspires me to add an example section. I think we need a section with a very simple sample PAD and SPD configuration as follows: - The PAD shall have one entry specifying a PKI trust anchor that peers' certificates must validate to. - The SPD will have a single PROTECT entry with address and port ranges for traffic selectors, and a single BYPASS entry for another set of addresses and ports. The protocol will be TCP in both cases. Events in the example will include: - Creation of a TCP listener - receipt of a TCP SYN for that listener and completion of the TCP handshake - An attempt to do establish a TCP connection for a different application - sending a TCP SYN - completion of the TCP handshake - Connection closing - Network events that result in conflicting SAD updates - Local conflicting SPD updates Nico -- From Nicolas.Williams at sun.com Tue Apr 8 16:59:25 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Apr 2008 18:59:25 -0500 Subject: [anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06] Message-ID: <20080408235925.GW16998@Sun.COM> Hannes sent this review and graciously allowed me to post it to the list. My responses will follow. Nico ----- Forwarded message from Hannes Tschofenig ----- Date: Tue, 08 Apr 2008 14:18:33 +0200 From: Hannes Tschofenig Subject: tsv-dir review of draft-ietf-btns-connection-latching-06 To: tsv-dir at ietf.org Cc: Nicolas.Williams at Sun.COM, julien.ietf at laposte.net, lha at stacken.kth.se I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir at ietf.org if you reply to or forward this review. I had to review draft-ietf-btns-connection-latching-06 and I have to admit that I did not follow the work in the BTNS group. Hence, I had to read through all the drafts to understand what you are doing. In some sense I am thankful to Magnus that he assigned me this task since I would not have looked at this work otherwise. Sorry that my review arrives so late. I couldn't see specific issues from a transport area directorate point of view related to this document. With this respect the document is essentially fine. Many aspects in the draft would, however, best be verified by an implementation. I hope that someone has done that. Is there code available? Still, I would like to share some my thoughts with you when I read through your specs. Initially, I thought I knew what I could expect under the title of "Better-Than-Nothing security". I was looking for a "leap of faith" type of solution. As it turns out that this is only one aspect (and probably the least important one) and the overall security at the end (with the application layer authentication and channel bindings) in some other deployment modes provides good and deployable security. The next trap was obviously the term "channel binding" since I knew it from EAP already and it may have a different meaning, at least RFC 5056 "On the Use of Channel Bindings to Secure Channels" claims that it is different even though I did not really understood the argument. There are some assumptions these channel bindings in this work are somewhat difficult to understand, at least for me. For example, here is the definition from RFC 5056: " o Channel binding: the process of establishing that no man-in-the- middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lower network layer. This term is used as a noun. " In some other places I got the impression that the authentication may happen at the application layer. I was wondering whether the ISO-OSI layer model is the important part of the story in order to capture the assumptions and applicability well (when the mechanism claims to be generic). The benefit of the work is also difficult to capture: * RFC 5056 indicates the benefit of the approach mainly related to performance. Example: " The main goal of channel binding is to be able to delegate cryptographic session protection to network layers below the application in hopes of being able to better leverage hardware implementations of cryptographic protocols. " * There is also the security aspect of providing security protection at the lower layer while authentication happens at the higher layers, such as transport protection from packet spoofing. This is described in draft-ietf-btns-prob-and-applic-06.txt (by potentially anticipating solutions in the BGP space). * draft-ietf-btns-prob-and-applic-06.txt points generally to benefits for different applications, such as the transport of voice-over-IP (VoIP), IMAP server communication, protecting transport connections for commercial web servers, transport for streaming media, file system protocols (such as iSCSI and NFS). * Finally, there are general discussions on the advantages providing security at lower layers and to avoid multiple authentication steps at different layers (see for example Section 2.2.3 of draft-ietf-btns-prob-and-applic-06.txt). The statements in Section 2.1.2 of draft-ietf-btns-prob-and-applic-06.txt ("Authentication Methods") appear wrong to me when considering EAP usage in IKEv2. The text says: "CA-signed certificates and pre-shared secrets are the only methods of authentications accepted by current IPsec and IKE specifications. " Reading through the documents I could imagine that some folks, who are supposed to be using some of these concepts, could get confused. Consider that you are also targeting application layer guys. They might not even come up with the idea to use IPsec and the documents have a heavy IPsec/IKE touch even though the concepts are more generally applicable (I believe). For example, when I look at http://tools.ietf.org/id/draft-johansson-http-tls-cb-02.txt that seems to fit into the entire stream of work. Maybe you went a bit too far with the abstraction and hence your work is not so easy to understand anymore. For example, the channel binding definition from RFC 5056 shown above does not fit nicely to something described in draft-johansson-http-tls-cb-02.txt; it more naturally fits into IPsec. I mentioned some of the benefits you see for your work. I would like to focus on one aspect only, namely VoIP security, since I worked in this space for a while now. As part of that work I never came across BTNS. On the other hand, nobody from the BTNS working group approached us either, particularly since you seem to assume that "we" are potential customers of your technology. I provide you a bit more details about what we do and maybe the stuff just sounds like "channel bindings" but in fact isn't. I don't know. In any case, it might show you that * you have not done a lot of marketing for your work (I hope you do not believe that everyone follows everything else going on in the IETF anyway and your work ends with writing a draft.) * every application case may be a bit different and there may not be so many usages for your stuff as you might think. For example, security vulnerabilities with TCP might not be a convincing argument for many people in the application area. They often have more severe attacks to worry about. In SIP we are working on a VoIP media security solution and after a long time we decided to go for DTLS-SRTP. The details don't matter but consider the following high-level framework http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt: +-----------+ +-----------+ |SIP | SIP/SDP |SIP | +------>|Proxy |----------->|Proxy |-------+ | |Server X | (+finger- |Server Y | | | +-----------+ print, +-----------+ | | +auth.id.) | | SIP/SDP SIP/SDP | | (+fingerprint) (+fingerprint,| | +auth.id.) | | | | v +-----------+ Datagram TLS +-----------+ |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | |User Agent | Media |User Agent | |Alice at X | <=================================> |Bob at Y | +-----------+ +-----------+ Legend: ------>: Signaling Traffic <-+-+->: Key Management Traffic <=====>: Data Traffic Figure 1: DTLS Usage in the SIP Trapezoid The entire exchange starts with a SIP traveling along the SIP proxy and carrying a fingerprint that identifies the certificate). The fingerprint story is essentially taken from http://www.ietf.org/rfc/rfc4572.txt. There are several ways one can do the authentication at the SIP layer; a more complicated story. Hence, just assume that Alice would be authenticated to Bob at the application layer (here SIP). The DTLS exchange between the end points is essentially not authenticated in many cases. To create a relationship between the SIP signaling session and the DTLS exchange (and the subsequent media) the fingerprint conveyed in the SIP exchange would refer to the certificate that will be presented for the TLS session. This might similar to your channel bindings idea even though we don't say anything about channel binding here at all (and I wouldn't even know why we should). We wouldn't make use of anything from draft-ietf-btns-connection-latching-06.txt or draft-ietf-btns-core-06.txt since we don't use IPsec. There are good reasons for not using IPsec in this space: SRTP is specifically designed for voice with a low overhead and the industry had already bought into it. The stuff is available in the respective devices in hardware. When we initially proposed RTP over DTLS (see http://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00) and we got beaten up for using the TLS record layer instead of SRTP. Consequence: We quickly changed to http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-00). There is, however, another document that could make use of some of your stuff, namely http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-06.txt. It uses IPsec (as HIP currently uses IPsec) but I have to admit that it belongs more to the academic track rather than something that is pending deployment. Also related to to this work there is an old 3GPP specification that uses IPsec between the SIP User Agent and it's outbound SIP proxy. It does not use IKE but uses the authentication and key exchange defined in SIP (digest authentication) and SIP security agreement to essentially accomplish the same functionality as IKE. There, I believe, your IPsec API concept could have been useful. Unfortunately, that was many years before you did your work and hence they already did their own stuff. I am also not sure about the widespread deployment. Ciao Hannes PS: A minor comment regarding the following statement: " o Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer. " I don't see how IKE would be able to obtain this information in a reliable fashion. I suggest to delete this paragraph. If you want to learn more about the complexity of NAT traversal I suggest to read through STUN, TURN, ICE and other BEHAVE documents. ----- End forwarded message ----- From Nicolas.Williams at sun.com Tue Apr 8 18:05:54 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Apr 2008 20:05:54 -0500 Subject: [anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06] In-Reply-To: <20080408121833.249870@gmx.net> Message-ID: <20080409010554.GN16999@Sun.COM> On Tue, Apr 08, 2008 at 14:18:33 +0200, Hannes Tschofenig wrote: > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. The authors should consider > this review together with any other last-call comments they > receive. Please always CC tsv-dir at ietf.org if you reply to or forward > this review. Thank you! > I had to review draft-ietf-btns-connection-latching-06 and I have to > admit that I did not follow the work in the BTNS group. Hence, I had > to read through all the drafts to understand what you are doing. In > some sense I am thankful to Magnus that he assigned me this task since > I would not have looked at this work otherwise. Sorry that my review > arrives so late. Thank you, that is a lot of reading. > I couldn't see specific issues from a transport area directorate point > of view related to this document. With this respect the document is > essentially fine. Thanks. I'm in the process of preparing -07, which will have some new material relevant to a tsv-dir review, namely listing the events for TCP, UDP and SCTP that cause creation/release of connection latches. These details are entirely obvious from -06, but I thought calling them out specifically would be useful, particularly for SCTP, whose multi-homing features might otherwise seem at odds with connection latching (it isn't). > Many aspects in the draft would, however, best be > verified by an implementation. I hope that someone has done that. Is > there code available? There exist two implementations, one in OpenSolaris and the other, IIRC, in OpenSwan. The OpenSolaris implementation is based on the informative model of connection latching in section 2.3 of -06, and it's not entirely complete, but it has been such as it is for years (since Solaris 9 was released). The source code is available at opensolaris.org and you can search it for ipsec_latch_t to get started. > Still, I would like to share some my thoughts with you when I read > through your specs. > > Initially, I thought I knew what I could expect under the title of > "Better-Than-Nothing security". I was looking for a "leap of faith" > type of solution. As it turns out that this is only one aspect (and > probably the least important one) and the overall security at the end > (with the application layer authentication and channel bindings) in > some other deployment modes provides good and deployable security. > > The next trap was obviously the term "channel binding" since I knew it > from EAP already and it may have a different meaning, at least RFC > 5056 "On the Use of Channel Bindings to Secure Channels" claims that > it is different even though I did not really understood the argument. > There are some assumptions these channel bindings in this work are > somewhat difficult to understand, at least for me. For example, here > is the definition from RFC 5056: > > " > o Channel binding: the process of establishing that no man-in-the- > middle exists between two end-points that have been authenticated > at one network layer but are using a secure channel at a lower > network layer. This term is used as a noun. > " > > In some other places I got the impression that the authentication may > happen at the application layer. I was wondering whether the ISO-OSI > layer model is the important part of the story in order to capture the > assumptions and applicability well (when the mechanism claims to be > generic). Authentication, indeed, is intended to happen at the application layer, but to keep things generic I opted to write of "network layers" (after all, the application layer is layer 7 in the OSI model, but authentication might happen at the presentation layer, as in RPCSEC_GSS, for example). > The benefit of the work is also difficult to capture: > > * RFC 5056 indicates the benefit of the approach mainly related to performance. Example: > " > The main goal of channel binding is to be able to delegate > cryptographic session protection to network layers below the > application in hopes of being able to better leverage hardware > implementations of cryptographic protocols. > " > > * There is also the security aspect of providing security protection > at the lower layer while authentication happens at the higher > layers, such as transport protection from packet spoofing. This is > described in draft-ietf-btns-prob-and-applic-06.txt (by potentially > anticipating solutions in the BGP space). That's one of several security benefits of channel binding. > * draft-ietf-btns-prob-and-applic-06.txt points generally to > benefits for different applications, such as the transport of > voice-over-IP (VoIP), IMAP server communication, protecting > transport connections for commercial web servers, transport for > streaming media, file system protocols (such as iSCSI and NFS). Indeed. I've not done any work towards applying BTNS, connection latching or channel binding to any of those areas. Except recently I've begun collaborating with others on channel binding to TLS for applications such as IMAP -- but that will not be using any BTNS WG technologies. > * Finally, there are general discussions on the advantages providing > security at lower layers and to avoid multiple authentication steps > at different layers (see for example Section 2.2.3 of > draft-ietf-btns-prob-and-applic-06.txt). > > The statements in Section 2.1.2 of > draft-ietf-btns-prob-and-applic-06.txt ("Authentication Methods") > appear wrong to me when considering EAP usage in IKEv2. The text > says: > > "CA-signed certificates and pre-shared secrets > are the only methods of authentications accepted by current IPsec and > IKE specifications. > " I think in the end-to-end IPsec case this is generally true, and in the SG use cases of IPsec it's generally false. The text could perhaps use some clarification on this point. > Reading through the documents I could imagine that some folks, who are > supposed to be using some of these concepts, could get confused. > Consider that you are also targeting application layer guys. They > might not even come up with the idea to use IPsec and the documents > have a heavy IPsec/IKE touch even though the concepts are more > generally applicable (I believe). For example, when I look at > http://tools.ietf.org/id/draft-johansson-http-tls-cb-02.txt that seems > to fit into the entire stream of work. Maybe you went a bit too far > with the abstraction and hence your work is not so easy to understand > anymore. For example, the channel binding definition from RFC 5056 > shown above does not fit nicely to something described in > draft-johansson-http-tls-cb-02.txt; it more naturally fits into IPsec. I think you must be referring to the trusted proxy termination of channels in draft-johansson-http-tls-cb-02. Although this notion is not described in RFC5056, it is a straightforward extension of the channel binding concept described in RFC5056. Leif, myself and others did consider whether to include that extension in RFC5056, but for want of finishing RFC5056 sooner, rather than later, we did not. > I mentioned some of the benefits you see for your work. I would like > to focus on one aspect only, namely VoIP security, since I worked in > this space for a while now. As part of that work I never came across > BTNS. On the other hand, nobody from the BTNS working group approached > us either, particularly since you seem to assume that "we" are > potential customers of your technology. I provide you a bit more > details about what we do and maybe the stuff just sounds like "channel > bindings" but in fact isn't. I don't know. In any case, it might show > you that * you have not done a lot of marketing for your work (I hope > you do not believe that everyone follows everything else going on in > the IETF anyway and your work ends with writing a draft.) Channel binding in general is, in fact gaining traction, and I think we'll soon see specifications for specific app protocols progressed and implementations deployed. > * every application case may be a bit different and there may not be > so many usages for your stuff as you might think. I agree. Channel binding has to be fit separately into each application that could benefit from it; it's not simply a matter of using existing channel binding "slots" in existing APIs -- even where they exist, as in the case of the GSS-API, there may be application-specific considerations that have to be taken into account. > For example, security vulnerabilities with TCP might not be a > convincing argument for many people in the application area. They > often have more severe attacks to worry about. I agree! > In SIP we are working on a VoIP media security solution and after a > long time we decided to go for DTLS-SRTP. The details don't matter but > consider the following high-level framework > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt: > > +-----------+ +-----------+ > |SIP | SIP/SDP |SIP | > +------>|Proxy |----------->|Proxy |-------+ > | |Server X | (+finger- |Server Y | | > | +-----------+ print, +-----------+ | > | +auth.id.) | > | SIP/SDP SIP/SDP | > | (+fingerprint) (+fingerprint,| > | +auth.id.) | > | | > | v > +-----------+ Datagram TLS +-----------+ > |SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP | > |User Agent | Media |User Agent | > |Alice at X | <=================================> |Bob at Y | > +-----------+ +-----------+ > > Legend: > ------>: Signaling Traffic > <-+-+->: Key Management Traffic > <=====>: Data Traffic > > Figure 1: DTLS Usage in the SIP Trapezoid > > > The entire exchange starts with a SIP traveling along the SIP proxy > and carrying a fingerprint that identifies the certificate). The > fingerprint story is essentially taken from > http://www.ietf.org/rfc/rfc4572.txt. There are several ways one can do > the authentication at the SIP layer; a more complicated story. > > Hence, just assume that Alice would be authenticated to Bob at the > application layer (here SIP). The DTLS exchange between the end points > is essentially not authenticated in many cases. To create a > relationship between the SIP signaling session and the DTLS exchange > (and the subsequent media) the fingerprint conveyed in the SIP > exchange would refer to the certificate that will be presented for the > TLS session. > > This might similar to your channel bindings idea even though we don't > say anything about channel binding here at all (and I wouldn't even > know why we should). This is, in fact, channel binding, in the RFC5056 sense. You don't have to state it for it to be so. > We wouldn't make use of anything from > draft-ietf-btns-connection-latching-06.txt or > draft-ietf-btns-core-06.txt since we don't use IPsec. Indeed, you wouldn't. The BTNS problem and applicability statement does claim that BTNS and connection latching and channel binding would be useful for such applications, and, indeed, use BTNS WG technology for SIP. BUT, DTLS was there, and it was available sooner than these other things (which, in fact, aren't yet available). So, yes, you wouldn't use IPsec for SIP. In my opinion this is a failing of IPsec: you can't even conceive of using IPsec for an application like SIP with Internet-scale deployment without first adding connection latching and IPsec APIs. > There are good > reasons for not using IPsec in this space: SRTP is specifically > designed for voice with a low overhead and the industry had already > bought into it. The stuff is available in the respective devices in > hardware. When we initially proposed RTP over DTLS (see > http://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00) and we > got beaten up for using the TLS record layer instead of SRTP. > Consequence: We quickly changed to > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-00). I was aware of this, and I agree. > There is, however, another document that could make use of some of > your stuff, namely > http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-06.txt. > It uses IPsec (as HIP currently uses IPsec) but I have to admit that > it belongs more to the academic track rather than something that is > pending deployment. HIP effectively uses channel binding. > PS: A minor comment regarding the following statement: > > " > o Implementations that provide such programming interfaces SHOULD > make available to applications any available NAT-related > information about the peer: whether it is behind a NAT and, if it > is, the inner and outer tunnel addresses of the peer. > " > > I don't see how IKE would be able to obtain this information in a > reliable fashion. I suggest to delete this paragraph. IKEv2 has a NAT traversal feature. I use it all the time. It works. Nico -- From julien.IETF at laposte.net Wed Apr 9 06:36:50 2008 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 9 Apr 2008 15:36:50 +0200 Subject: [anonsec] Fwd: Review of draft-ietf-btns-abstract-api-01 Message-ID: <200804091536.50852.julien.IETF@laposte.net> Folks, Vijay Gurbani has reviewed the BTNS abstract API and kindly agreed to let me forward it to the mailing list, please see it below. Many thanks to Vijay! --julien -------------- next part -------------- An embedded message was scrubbed... From: "Vijay K. Gurbani" Subject: Review of draft-ietf-btns-abstract-api-01 Date: Mon, 07 Apr 2008 14:45:15 -0500 Size: 10698 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20080409/2ff37960/attachment-0001.mht From Nicolas.Williams at sun.com Wed Apr 9 08:40:34 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 10:40:34 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <47FCD8DE.6020806@orange-ftgroup.com> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <47FCD8DE.6020806@orange-ftgroup.com> Message-ID: <20080409154034.GA16998@Sun.COM> On Wed, Apr 09, 2008 at 04:55:26PM +0200, Daniel Migault wrote: > >I think we want something like: > > > > o INFORM(5-tuple, BREAK | SUSPEND) > > > >There's no return value for this function. > > > If it means messages will be only "BREAK" or "SUSPEND", I don't see now > other kind of messages for now, but I am not absolutely certain there > will not be other kind of messages (informative, log messages for > example....) There's a third message: "restored" (for transitions from SUSPENDED to ESTABLISHED). From Nicolas.Williams at sun.com Wed Apr 9 08:50:05 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 10:50:05 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <47FCD90D.1000007@orange-ftgroup.com> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080407193811.GK16998@Sun.COM> <47FCD90D.1000007@orange-ftgroup.com> Message-ID: <20080409155004.GB16998@Sun.COM> On Wed, Apr 09, 2008 at 04:56:13PM +0200, Daniel Migault wrote: > Your figure is probably clearer than mine, and it is better to separate > the esp/ah layer from the key management layer. > The logical SPD is the combination of decorrelated SPD and ULP-driven > SPD. The figure mentions interaction between IKEv2 and the Logical SPD, > but I don't see interaction between UPL and the logical SPD. Maybe one > could add one arrow between ULP and the logical SPD. Yes, I need to fix that. It needs to be more like this: +--------------------------------------------+ | +--------------+ | | |Administrator | | | |apps | | | +--------------+ | | ^ ^ | | | | | user mode | v v | | +--------------+ +-------++--------+ | | |App | |IKEv2 || | | | | | | +---+ || +----+ | | | | | | |PAD| || |SPD | | | | | | | +---+ || +--^-+ | | | +--------------+ +-+-----++----+---+ | | ^ | | | +---|---------------------|-----------|------+ user/kernel mode | |syscalls | PF_KEY | | interface +---|---------------------|-----------|------+ | v | | | |+-------+ +------------|-----------|-----+| ||ULP | | IPsec key|manager | || |+-------+ | | +--------v----+|| | ^ ^ | | | Logical SPD ||| | | | | | +-----------^-+|| | | | | +-------+ | || kernel mode | | | | | | || | | | | +----------+ +--v--+ | || | | +-------->| Latch DB |<-->| SAD | | || | | | +----------+ +--^--+ | || | | +--------------------|------|--+| +-|-------------------------------v------v---+ | | IPsec Layer (ESP/AH) | | | | +-v------------------------------------------+ | IP Layer | +--------------------------------------------+ From Nicolas.Williams at sun.com Wed Apr 9 08:51:39 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 10:51:39 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <47FCD94F.6040108@orange-ftgroup.com> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> Message-ID: <20080409155138.GC16998@Sun.COM> On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote: > >Never mind. I've written one: > > > Here are my comments they might result from mis-interpretation of the > draft, but that how I understood it. > > On the figure there is a transition from LISTEN to ESTABLISH state. I > might be wrong but I understood LISTEN state as an established state for > Listener connection Latch. So I would not expect transition from > LISTEN to ESTABLISHED state. The only transition would be from LISTEN to > CLOSE state. I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED latches. I thinkI'll just add text to the diagram, or use a different style of line. From Nicolas.Williams at sun.com Wed Apr 9 10:00:22 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 12:00:22 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080409155138.GC16998@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> Message-ID: <20080409170021.GE16998@Sun.COM> On Wed, Apr 09, 2008 at 10:51:39AM -0500, Nicolas Williams wrote: > On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote: > > >Never mind. I've written one: > > > > > Here are my comments they might result from mis-interpretation of the > > draft, but that how I understood it. > > > > On the figure there is a transition from LISTEN to ESTABLISH state. I > > might be wrong but I understood LISTEN state as an established state for > > Listener connection Latch. So I would not expect transition from > > LISTEN to ESTABLISHED state. The only transition would be from LISTEN to > > CLOSE state. > > I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED > latches. I thinkI'll just add text to the diagram, or use a different > style of line. OK, how about this: | | v +--------+ / +----..|LISTENER|........ | : +--------+ : / | / | (e.g., TCP SYN receipt, + | : connect() call) : | | : v v | : +-----------+ | : +------|ESTABLISHED| | : | +--+-----^--+ | : | | | : | | | v | | : | +------------+-------+ | :........|.>|SUSPENDED (OPTIONAL)| | : | +---------+----------+ | : v | | : +------+ | | :.....>|BROKEN| | | +-+----+ +----------------------+ | | | |Legend: | | | | dotted lines denote | | | v | latch creation | | +------+ | solid lines denote | +-------------+--------> |CLOSED| | state transition | +------+ +----------------------+ PS: ASCII art drawing is fun! From Nicolas.Williams at sun.com Wed Apr 9 10:36:33 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 12:36:33 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <47FCFFEA.7020004@orange-ftgroup.com> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> Message-ID: <20080409173633.GF16998@Sun.COM> On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote: > It sounds good for me, maybe we should also add dot lines with the > CREATE_CONNECTION_LATCH function. Consider it done. > Can the LISTEN state be considered as something like a "larval state"? Yes. > Should we introduce in the same manner a CONNECTION state so that > listeners and connections object have similar state architecture? I guess I could. I'll play with it. This diagram is fairly busy though and I want to keep it simple. It needn't capture every subtlety :) Nico -- From Nicolas.Williams at sun.com Wed Apr 9 11:12:39 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 13:12:39 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080409173633.GF16998@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> Message-ID: <20080409181238.GG16998@Sun.COM> On Wed, Apr 09, 2008 at 12:36:33PM -0500, Nicolas Williams wrote: > On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote: > > It sounds good for me, maybe we should also add dot lines with the > > CREATE_CONNECTION_LATCH function. > > Consider it done. > > > Can the LISTEN state be considered as something like a "larval state"? > > Yes. > > > Should we introduce in the same manner a CONNECTION state so that > > listeners and connections object have similar state architecture? > > I guess I could. I'll play with it. This diagram is fairly busy though > and I want to keep it simple. It needn't capture every subtlety :) OK, here it is. I think this is as busy as I want the state machine diagram to be. : : : v +--------+ : +------|LISTENER|........ : +----------------------+ | : +--------+ : : |Legend: | | : | dotted lines denote | | (e.g., TCP SYN receipt, : | latch creation | | : connect() call) : : | | | : v v | solid lines denote | | : +-----------+ | state transition | | : +------|ESTABLISHED| +----------------------+ | : | +-----------+ | : | | ^ | : | | | : | | | v | | : | +--------------------+ | :........|...>|SUSPENDED (OPTIONAL)| | : | +--------------------+ | : v | | : +------+ | | :.....>|BROKEN| | | +-+----+ | | | | | | | v | +---------------------------------+ | | |CLOSED (common to LISTENER and | +-------------+--------->| CONNECTION latches both) | +---------------------------------+ From Nicolas.Williams at sun.com Wed Apr 9 21:25:56 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 9 Apr 2008 23:25:56 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080409181238.GG16998@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> Message-ID: <20080410042555.GF8027@Sun.COM> Thinking it over, the SUSPENDED and BROKEN states differ only in whether an implementation supports transitioning from SUSPENDED to ESTABLISHED. That difference is too small to warrant two states. So I'm going to merge those two states. That will make the state diagram simpler. Nico -- From mglt.biz at gmail.com Thu Apr 10 07:22:02 2008 From: mglt.biz at gmail.com (Daniel Migault) Date: Thu, 10 Apr 2008 16:22:02 +0200 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080410042555.GF8027@Sun.COM> References: <20080225093002.01ABB3A6CB2@core3.amsl.com> <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> Message-ID: On Thu, Apr 10, 2008 at 6:25 AM, Nicolas Williams wrote: > Thinking it over, the SUSPENDED and BROKEN states differ only in whether > an implementation supports transitioning from SUSPENDED to ESTABLISHED. > I personally like the idea of the SUSPEND state which is the state where problems have to be solved, as opposed to the ESTABLISHED state where Latched objects are running properly. Maybe there is a solution to drop the SUSPEND state and merge it with the BROKEN state by considering different transition condition from ESTABLISHED to BROKEN. I don't think we have too many states, and I eventually would add CONECTION larval state for LC objects. On the other hand, if I really had to drop one state I would rather drop larval state like the LISTEN state. > > That difference is too small to warrant two states. > > So I'm going to merge those two states. That will make the state > diagram simpler. > > Nico > -- Daniel -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080410/c46eb586/attachment.html From Nicolas.Williams at sun.com Thu Apr 10 08:19:42 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Apr 2008 10:19:42 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: References: <20080407180003.GB16998@Sun.COM> <20080408173036.GS16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> Message-ID: <20080410151942.GH8027@Sun.COM> On Thu, Apr 10, 2008 at 04:22:02PM +0200, Daniel Migault wrote: > Maybe there is a solution to drop the SUSPEND state and merge it with the > BROKEN state by considering different transition condition from ESTABLISHED > to BROKEN. That's exactly what I did: : v /--------\ : : +------|LISTENER|...... : : | \--------/ : : : +--------------------+ | : : : : |Legend: | | : : : : | dotted lines denote| | : : | latch creation | | (e.g., TCP SYN : : : | | | received, : : : | solid lines denote | | connect() : : : | state transition| | called, ...) v v : | | | : /-----------\ : | semi-solid lines | | : |ESTABLISHED| : | denote async | | \-----------/ : | notification | | : ^ | : +--------------------+ | : | | : | : | : (OPTIONAL) | : | : | v v | : /----------------\ | :.....>| BROKEN |.-.-.-.-.-> | \----------------/ | | | | | v | /------\ +------------------->|CLOSED| \------/ > I don't think we have too many states, and I eventually would add CONECTION > larval state for LC objects. On the other hand, if I really had to drop one > state I would rather drop larval state like the LISTEN state. Check out the above diagram. I think it's simple enough now. Nico -- From mglt.biz at gmail.com Thu Apr 10 09:10:57 2008 From: mglt.biz at gmail.com (Daniel Migault) Date: Thu, 10 Apr 2008 18:10:57 +0200 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-06.txt In-Reply-To: <20080410151942.GH8027@Sun.COM> References: <20080407180003.GB16998@Sun.COM> <47FCD94F.6040108@orange-ftgroup.com> <20080409155138.GC16998@Sun.COM> <20080409170021.GE16998@Sun.COM> <47FCFFEA.7020004@orange-ftgroup.com> <20080409173633.GF16998@Sun.COM> <20080409181238.GG16998@Sun.COM> <20080410042555.GF8027@Sun.COM> <20080410151942.GH8027@Sun.COM> Message-ID: This one is really great! Distinction of creation, state transition and notification with different lines really helps to clarify it! Daniel On Thu, Apr 10, 2008 at 5:19 PM, Nicolas Williams wrote: > On Thu, Apr 10, 2008 at 04:22:02PM +0200, Daniel Migault wrote: > > Maybe there is a solution to drop the SUSPEND state and merge it with > the > > BROKEN state by considering different transition condition from > ESTABLISHED > > to BROKEN. > > That's exactly what I did: > > > : > v > /--------\ : : > +------|LISTENER|...... : : > | \--------/ : : : +--------------------+ > | : : : : |Legend: | > | : : : : | dotted lines denote| > | : : | latch creation | > | (e.g., TCP SYN : : : | | > | received, : : : | solid lines denote | > | connect() : : : | state transition| > | called, ...) v v : | | > | : /-----------\ : | semi-solid lines | > | : |ESTABLISHED| : | denote async | > | \-----------/ : | notification | > | : ^ | : +--------------------+ > | : | > | : | : cleared> | : > | : (OPTIONAL) | : > | : | v v > | : /----------------\ > | :.....>| BROKEN |.-.-.-.-.-> > | \----------------/ > | | > > | | > | v > | /------\ > +------------------->|CLOSED| > \------/ > > > I don't think we have too many states, and I eventually would add > CONECTION > > larval state for LC objects. On the other hand, if I really had to drop > one > > state I would rather drop larval state like the LISTEN state. > > Check out the above diagram. I think it's simple enough now. > > Nico > -- > -- Daniel Migault Orange Labs / Security Lab +33 (0) 1 45 29 60 52 +33 (0) 6 70 72 69 58 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20080410/7321fb89/attachment.html From julien.IETF at laposte.net Mon Apr 14 00:34:45 2008 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 14 Apr 2008 09:34:45 +0200 Subject: [anonsec] Fwd: Review of draft-ietf-btns-c-api-03 Message-ID: <200804140934.46272.julien.IETF@laposte.net> Folks, Vijay Gurbani has reviewed the BTNS C API and kindly agreed to let me forward it to the mailing list, please see it below. Many thanks to Vijay! --julien -------------- next part -------------- An embedded message was scrubbed... From: "Vijay K. Gurbani" Subject: Review of draft-ietf-btns-c-api-03 Date: Sat, 12 Apr 2008 17:36:16 -0500 Size: 7973 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20080414/4a90695a/attachment.mht From Internet-Drafts at ietf.org Mon Apr 14 20:15:01 2008 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 14 Apr 2008 20:15:01 -0700 (PDT) Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-07.txt Message-ID: <20080415031502.02ED83A6DE2@core3.amsl.com> From Nicolas.Williams at sun.com Tue Apr 15 07:31:57 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Apr 2008 09:31:57 -0500 Subject: [anonsec] Changes for draft-ietf-btns-connection-latching-07 Message-ID: <20080415143157.GH8027@Sun.COM> At Philadelphia I had a conversation with Daniel Migault about connection latching. Daniel's main insight was that the key task for us in this I-D was to make absolutely clear what is the impact of this work on the IPsec architecture, and that that impact is minimal, or none even. Daniel subsequently posted suggested text and ASCII art, and though I used very little of that text as is, Daniel's text and art inspired me to follow along those lines. So I made the following changes: - Simplified and clarified the connection latch state machine, including a state machine diagram. - Tailored the description of the normative model of connection latching to make clear that at its bare minimum it's just a purely local conflict detection and notification mechanism. - All features whereby local policy is logically updated are now optional, with clear warnings that no such logical policy updates survive reboots. - Added text to the security considerations section about the impact of this feature on the IPsec architecture. The impact of optional features is described in a separate section. - Added an informative diagram showing the relationships between various components of an IPsec w/ connection latching system, all in terms likely to be understood by operating systems developers. - Added a section describing how connection latching works for each of the three major transport protocols, even though all the details therein follow from the remainder of the draft. I thought it would be good to show that the details relating to SCTP were as simple as those relating to TCP. The URL to the rfcdiff tool for the diffs between -06 and -07 is: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-btns-connection-latching-06.txt&url2=http://tools.ietf.org/id/draft-ietf-btns-connection-latching-07.txt [No, I've not yet spell-checked -07. I just noticed I misspelt "simultaneous" -- how embarrassing.] Nico -- From Nicolas.Williams at sun.com Mon Apr 21 13:57:58 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 21 Apr 2008 15:57:58 -0500 Subject: [anonsec] WGLC for connection-latching-07 (Re: Changes for draft-ietf-btns-connection-latching-07) In-Reply-To: <20080415143157.GH8027@Sun.COM> References: <20080415143157.GH8027@Sun.COM> Message-ID: <20080421205758.GM13552@Sun.COM> Julian, Love, I think draft-ietf-btns-connection-latching-07 is ready for WGLC. Early May would be great. Nico -- From julien.IETF at laposte.net Wed Apr 23 08:50:51 2008 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 23 Apr 2008 17:50:51 +0200 Subject: [anonsec] WGLC for connection-latching-07 (Re: Changes for draft-ietf-btns-connection-latching-07) In-Reply-To: <20080421205758.GM13552@Sun.COM> References: <20080415143157.GH8027@Sun.COM> <20080421205758.GM13552@Sun.COM> Message-ID: <200804231750.52177.julien.IETF@laposte.net> On Monday 21 April 2008, Nicolas Williams wrote: > Julian, Love, > > I think draft-ietf-btns-connection-latching-07 is ready for WGLC. > Early May would be great. All right. Let's do that then. --julien