下载文档原格式
iisapi 原理iisapi介绍在Web开发中，为了实现对IIS服务器的扩展和自定义功能，可以使用iisapi (Internet Information Services Application Programming Interface)。
iisapi是一种基于COM的接口，可用于开发IIS网络服务器的第三方插件和扩展。
架构iisapi的架构主要由以下几个组件组成：•****：这是iisapi的核心组件，包含了与IIS服务器通信和处理请求的功能。
•ISAPI过滤器：过滤器是iisapi的一个重要组件，它可以实现对HTTP请求和响应进行拦截和过滤。
通过注册一个ISAPI过滤器，可以在请求到达IIS之前或响应返回客户端之前对请求和响应进行加工和处理。
•ISAPI扩展：扩展是一种特殊的ISAPI过滤器，它能够直接处理除HTTP请求和响应以外的其他类型的请求，比如FTP、SMTP等。
扩展可以以动态链接库(DLL)的形式提供，通过注册一个网络服务扩展来将其绑定到特定的网站或虚拟目录上。
工作原理iisapi的工作原理可以简要概括为以下几个步骤：1.客户端发送HTTP请求到IIS服务器。
2.IIS服务器接收到请求后，将请求传递给已注册的ISAPI过滤器。
3.ISAPI过滤器根据自定义的逻辑对请求进行过滤、加工或拦截。
4.处理完毕后，ISAPI过滤器将请求传递给IIS进行处理，或者直接返回响应给客户端。
5.如果请求需要使用ISAPI扩展处理，则IIS将请求传递给对应的扩展处理。
6.扩展根据自定义逻辑处理请求，并生成相应的响应数据。
7.IIS将生成的响应数据返回给客户端。
开发步骤使用iisapi进行开发一般包括以下几个步骤：1.创建ISAPI过滤器或扩展的项目：在开发环境中创建一个新的iisapi项目，需要选择对应的语言和开发工具。
2.编写自定义的处理逻辑：根据需求，编写自定义的处理逻辑，可以包括请求拦截、过滤、加工等操作。
1)100 Trying说明caller正在呼叫，但还没联系上callee。
180 Ringing 说明callee已经被联系上,callee的铃正在响.收到这个信息后，等待200 OK2)181 Call is being forwarded说明call被重新路由到另外一个目的地3)182 Queued说明callee当前是不可获得的，但是对方不想直接拒绝呼叫，而是选择放在呼叫队列中4)183 Session progress用来警告caller频段(inband)错误。
当从PSTN收到一个ISDN消息，SIP gateway 产生183 Session progress 。
建立专有承载QCI12xx successful Responses200 OK3xx Redirection Responses5)300 Multiple choices说明呼叫的地址被解析成多个地址，所有的地址都被提供出来，用户或用户代理可以从中选择联系哪个。
6)301 Moved permanently说明指定地址的用户已经永远不可用，在头中已经用另外一个地址替换了.7)302 Moved temporarily说明指定地址的用户临时不可用，在头中已经用另外一个地址代替了.8)305 Use proxy说明caller必须用一个proxy来联系callee.9)380 Alternative service说明call不成功，但是可选择其他的服务4xx Request Failure Responses10)400 Bad Request说明由于非法格式，请求不能被理解。
11)401 Unauthorized说明请求需要用户认证。
12)402 Payment required说明完成会话需要付费.13)403 Forbidden说明server已经收到并能理解请求但不提供服务。
14)404 Not Found说明server有明确的信息在指定的域中用户不存在.15)405 Method Not Allowed说明请求中指定的方法是不被允许的。
IIS短⽂件名漏洞复现图⽂详解⼀、漏洞描述此漏洞实际是由HTTP请求中旧DOS 8.3名称约定(SFN)的代字符(~)波浪号引起的。
它允许远程攻击者在Web根⽬录下公开⽂件和⽂件夹名称(不应该可被访问)。
攻击者可以找到通常⽆法从外部直接访问的重要⽂件,并获取有关应⽤程序基础结构的信息。
⼆、漏洞原理IIS的短⽂件名机制,可以暴⼒猜解短⽂件名,访问构造的某个存在的短⽂件名,会返回404,访问构造的某个不存在的短⽂件名,返回400。
漏洞成因:为了兼容16位MS-DOS程序,Windows为⽂件名较长的⽂件(和⽂件夹)⽣成了对应的windows 8.3短⽂件名。
在Windows下查看对应的短⽂件名,可以使⽤命令dir /x短⽂件名特征:1.只显⽰前6位的字符,后续字符⽤~1代替。
其中数字1是可以递增。
如果存在⽂件名类似的⽂件,则前⾯的6个字符是相同的,后⾯的数字进⾏递增2.后缀名最长只有3位,超过3位的会⽣成短⽂件名,且后缀多余的部分会截断。
3.所有⼩写字母均转换成⼤写的字母4.长⽂件名中包含多个”.”的时候,以⽂件最后⼀个”.”作为短⽂件名的后缀5.长⽂件名前缀/⽂件夹名字符长度符合0-9和A-Z、a-z范围且需要⼤于等于9位才会⽣成短⽂件名,如果包含空格或者其他部分特殊字符,不论长度均会⽣成短⽂件。
三、漏洞环境搭建及漏洞复现1、测试环境为windows server 2003 r2,开启webdav服务和net服务。
2、使⽤payload验证⽬标是否存在IIS短⽂件名漏洞,下图显⽰的404,说明⽬标存在该短⽂件名注:*可以匹配n个字符,n可以为03、浏览器访问⼀个不存在的短⽂件名,返回”Bad Request(400)”,说明⽬标不存在该短⽂件名4、通过浏览器访问上⾯两个payload,根据返回的结果,可以说明⽬标存在IIS短⽂件漏洞5、判断漏洞存在后,接下来⼿⼯详细分析猜解IIS短⽂件名原理5.1、在⽹站根⽬录(C:\Inetpub\wwwroot)下创建⼀个abcdef123456.txt⽂件5.3、通过以上两个图⽚,可以看出存在⼀个以a开头的短⽂件名5.7、⽤a-z的26个字母依次替换上述a的位置,当替换成t时,返回404页⾯,说明该短⽂件的第⼀位后缀是t5.8、按照上⾯的⽅法依次猜解得到该短⽂件名的后缀是txt5.9、到此为⽌,已经猜解出该短⽂件名为abcdef~1.txt6、根据已经猜解出来的短⽂件名abcdef~1.txt,继续猜解出该短⽂件名的完全⽂件名为abcdef123456.txt7、使⽤IIS短⽂件名扫描软件，获取⽬标存在哪些短⽂件名四、漏洞防御1、升级.net framework2、修改注册表键值：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem修改NtfsDisable8dot3NameCreation为1。
中国移动通信企业标准 家庭网关终端技术规范版本号：3.0.0 中国移动通信集团公司 发布╳╳╳╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施 QB-╳╳-╳╳╳-╳╳╳╳T e c h n i c a l S p e c if i c a t i o n f o r H o m e G a t e w a y目录1. 范围 ................................................................................................................................................2. 规范性引用文件 .............................................................................................................................3. 术语、定义和缩略语 .....................................................................................................................4. 设备总体定义.................................................................................................................................4.1.设备在网络中的位置 ..................................................................................................................4.2.接口定义 ......................................................................................................................................4.3.设备类型 ......................................................................................................................................5. 接入型家庭网关 .............................................................................................................................5.1.接口要求 ......................................................................................................................................网络侧接口......................................................................................................................................网络侧接口描述..........................................................................................................................................网络侧以太网接口要求..............................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................接口要求 .......................................................................................................................................................用户侧接口......................................................................................................................................用户侧以太网接口要求..............................................................................................................................接口 ...............................................................................................................................................................接口（可选）................................................................................................................................................5.2.功能要求 ......................................................................................................................................数据通信要求..................................................................................................................................协议要求 .......................................................................................................................................................数据转发功能要求......................................................................................................................................功能要求 .......................................................................................................................................................地址管理及拨号管理功能要求....................................................................................................................地址管理及拨号管理功能要求....................................................................................................................要求 ...............................................................................................................................................................要求 ...............................................................................................................................................................组播要求 .....................................................................................................................................................其他功能要求..............................................................................................................................................安全要求..........................................................................................................................................防火墙 .........................................................................................................................................................登陆WEB页面的安全要求..........................................................................................................................设备安全性 .................................................................................................................................................要求....................................................................................................................................................功能要求............................................................................................................................................扩展及管理（可选）........................................................................................................................设备发现要求.........................................................................................................................................................................................................................................................................................................（可选） .......................................................................................................................................................支持WLAN的开启和禁用............................................................................................................................基本要求 .....................................................................................................................................................多SSID要求................................................................................................................................................安全要求 .......................................................................................................................................................5要求 ............................................................................................................................................................要求 ...............................................................................................................................................................基本应用要求................................................................................................................................... WLAN共享 ..................................................................................................................................................家庭存储（可选）......................................................................................................................................5.3.性能要求 ......................................................................................................................................路由转发性能要求..........................................................................................................................吞吐量 .........................................................................................................................................................地址学习 .....................................................................................................................................................缓存大小 (23)连接数量要求.............................................................................................................................................. 无线性能要求....................................................................................................................................吞吐量性能要求 (23)覆盖性能要求................................................................................................................................................接收灵敏度要求............................................................................................................................................5.4.管理和维护要求 (24)本地管理和配置要求......................................................................................................................本地管理基本要求......................................................................................................................................用户分级管理 (24)系统信息管理..............................................................................................................................................基本配置 .....................................................................................................................................................高级配置 .....................................................................................................................................................设备管理 .....................................................................................................................................................网络诊断 .....................................................................................................................................................设备认证注册功能......................................................................................................................................远程管理要求..................................................................................................................................远程管理基本要求......................................................................................................................................远程参数配置和性能监测..........................................................................................................................远程故障诊断功能......................................................................................................................................设备告警功能..............................................................................................................................................远程链路维持功能......................................................................................................................................软件远程管理..............................................................................................................................................业务部署和控制..........................................................................................................................................上行家庭网关远程管理实现方式 ................................................................................................................日志功能要求..................................................................................................................................5.5.预配置要求 ..................................................................................................................................预配置要求......................................................................................................................................5.6.硬件要求 ......................................................................................................................................基本要求..........................................................................................................................................硬件基本框图示例..........................................................................................................................5.7.软件要求 ......................................................................................................................................基本要求..........................................................................................................................................软件基本架构................................................................................................. 错误!未定义书签。
sip isregistered方法SIP（Session Initiation Protocol）是一种用于建立、修改和终止多媒体会话的通信协议。
其中的isRegistered方法是一种用于查询SIP用户注册状态的功能。
isRegistered方法的作用是检查特定的SIP地址是否已在SIP服务器上注册。
在SIP协议中，用户代理（User Agent）需要在发起或接收会话之前先向SIP服务器注册。
isRegistered方法可以帮助开发者确定某个SIP地址是否成功地完成了注册过程。
通过调用isRegistered方法，开发者可以判断一个特定的SIP用户是否在线和可用。
这对于实时通信应用程序尤其重要，因为它们需要准确地确定用户的在线状态。
isRegistered方法通常返回一个布尔值，如果指定的SIP地址已成功注册，则返回true；如果未注册或注册失败，则返回false。
使用isRegistered方法可以实现一些实用的功能。
例如，在一个即时通信应用程序中，可以利用这个方法来检查用户是否处于在线状态，并根据其状态来采取不同的操作，比如发送实时消息或者提示用户不在线。
对于开发者而言，使用isRegistered方法还需要注意以下几点：1. 需要提供合法的SIP地址作为参数，以便查询该地址的注册状态。
2. 在使用isRegistered方法前，需要确保已经建立了与SIP服务器的连接，并且获得了相应的权限。
3. 在处理方法返回的布尔值时，需要针对不同的情况进行逻辑判断和处理。
如果返回值为true，表示用户已经注册成功，可以进行相应的操作；如果返回值为false，可能需要通过其他方式提醒用户进行注册或重新尝试。
总之，SIP的isRegistered方法为开发者提供了快速查询SIP用户注册状态的功能。
通过合理利用这个方法，可以更好地实现实时通信应用程序，并提升用户体验。
SIP安全协议SIP（Session Initiation Protocol）是一种用于控制多媒体会话的协议，常用于互联网电话服务、语音和视频会议等领域。
由于其在传输过程中存在安全风险，因此需要采取相应的安全协议来保护通信内容和用户身份信息。
本文将介绍几种常见的SIP安全协议和其工作原理。
一、SIP中的安全问题SIP作为一种应用层协议，其安全问题主要包括信息泄露、拒绝服务攻击和身份伪造等。
攻击者可以通过监听SIP通信获取用户信息，篡改通信内容或阻断通信服务。
为了解决这些问题，SIP安全协议应运而生。
二、S/MIME（Secure/Multipurpose Internet Mail Extensions）S/MIME是一种基于公钥加密的SIP安全协议。
它通过数字证书将加密和签名应用于SIP会话中的消息，确保消息的机密性和完整性。
S/MIME使用RSA算法对会话进行加密，并通过数字签名验证发送者的身份。
这种方式能够有效地防止信息泄露和身份伪造等问题。
三、TLS（Transport Layer Security）TLS是一种传输层安全协议，在SIP通信中主要用于建立安全的传输通道。
它通过握手过程实现通信双方的身份验证，并使用对称加密算法保护数据的机密性。
TLS能够有效地抵御监听和中间人攻击等安全威胁，提供安全可靠的通信环境。
四、SIP认证机制SIP认证机制是一种基于用户名和密码的安全协议，用于防止未经授权的访问。
当用户发起SIP会话时，需要提供正确的用户名和密码进行认证。
常见的SIP认证机制包括基本认证（Basic Authentication）和摘要认证（Digest Authentication）。
这种方式可以防止身份伪造和未授权访问等风险。
五、防止拒绝服务攻击拒绝服务攻击是SIP通信中的一种常见威胁，攻击者通过发送大量无效请求或僵尸请求，使得服务无法正常处理合法请求。
为了解决这个问题，可以采用带宽限制、请求频率控制和会话授权等策略来限制恶意请求的影响，保证正常用户的通信质量。
Network Working Group R. Mahy Request for Comments: 3891 Cisco Systems, Inc. Category: Standards Track B. Biggs R. Dean September 2004 The Session Initiation Protocol (SIP) "Replaces" HeaderStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004).AbstractThis document defines a new header for use with Session InitiationProtocol (SIP) multi-party applications and call control. TheReplaces header is used to logically replace an existing SIP dialogwith a new SIP dialog. This primitive can be used to enable avariety of features, for example: "Attended Transfer" and "CallPickup". Note that the definition of these example features is non- normative.Mahy, et al. Standards Track [Page 1]Table of Contents1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 22. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 43. User Agent Server Behavior: Receiving a Replaces Header . . . 44. User Agent Client Behavior: Sending a Replaces Header . . . . 65. Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . . 76. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. The Replaces Header . . . . . . . . . . . . . . . . . . 76.2. New Option Tag for Require and Supported Headers. . . . 87. Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . 97.1. Replacing an Early Dialog at the Originator . . . . . . 98. Security Considerations . . . . . . . . . . . . . . . . . . . 119. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. Registration of "Replaces" SIP Header . . . . . . . . . 139.2. Registration of "replaces" SIP Option-tag . . . . . . . 1310. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 1311. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References. . . . . . . . . . . . . . . . . . 1311.2. Informative References. . . . . . . . . . . . . . . . . 1412. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 1513. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 1. OverviewThis document describes a SIP [1] extension header field as part ofthe SIP multiparty applications architecture framework [10]. TheReplaces header is used to logically replace an existing SIP dialogwith a new SIP dialog. This is especially useful in peer-to-peercall control environments.One use of the "Replaces" header is to replace one participant withanother in a multimedia conversation. While this functionality isalready available using 3rd party call control [11] style callcontrol, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method ofperforming these same call control primitives in a distributed,peer-to-peer fashion is very desirable.Use of a new INVITE with a new header for dialog matching was chosen over making implicit associations in an incoming INVITE based oncall-id or other fields for the following reasons:o An INVITE already has the correct semantics for a new callo Using an explicit Replaces header in a new request makes theintent of the request obvious.Mahy, et al. Standards Track [Page 2]o A unique call-id may be given to the replacement call. Thisavoids dialog matching problems in any of the related User Agents. o There are no adverse effects if the header is unsupported.The Replaces header enables services such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a distributed peer-to-peer way. This list ofservices is not exhaustive. Although the Replaces header isfrequently used in combination with the REFER [8] method as used in a Transfer [12], they may be used independently.For example, Alice is talking to Bob from phone1. She transfers Bob to a Parking Place while she goes to the lab. When she gets thereshe retrieves the "parked" call from phone2 by sending an INVITE with a Replaces header field to Bob with the dialog information Bob shared with the Parking Place. Alice got this information using some out of band mechanism. Perhaps she subscribed to this information from the Parking Place (using the session dialog package [13]), or went to awebsite and clicked on a URI. A short call flow for this examplefollows. (Via and Max-Forwards headers are omitted for clarity.)Alice Alice Parkingphone1 phone2 Bob Place| | | ||<===============================>| || | | || Alice transfers Bob to Parking Place || | | ||------------REFER/200----------->| *1 *2 ||<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->||<--NOTIFY/200 (success)----------|<=================>||------------BYE/200------------->| || | | || | | || Alice later retrieves call from another phone || | | || *3 |-INV w/Replaces->| || |<--200-----------| || |---ACK---------->|----BYE/200------->|| |<===============>| || | | |Mahy, et al. Standards Track [Page 3]Message *1: Bob-> Parking PlaceINVITE sip:parkingplace@ SIP/2.0To: <sip:parkingplace@>From: <sip:bob@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:bob@>Referred-By: <sip:alice@>Message *2: Parking Place -> BobSIP/2.0 200 OKTo: <sip:parkingplace@>;tag=6472From: <sip:bob@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:parkplace@>Message *3: Alice@phone2 -> BobINVITE sip:bob@To: <sip:bob@>From: <sip:alice@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:alice@>Require: replacesReplaces: 425928@;to-tag=7743;from-tag=64722. ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. This document refers frequently to the terms "confirmed dialog" and"early dialog". These are defined in Section 12 of SIP [1].3. User Agent Server Behavior: Receiving a Replaces HeaderThe Replaces header contains information used to match an existingSIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Replaces header, the User Agent (UA) attempts to match thisinformation with a confirmed or early dialog. The User Agent Server (UAS) matches the to-tag and from-tag parameters as if they were tags Mahy, et al. Standards Track [Page 4]present in an incoming request. In other words, the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE,the UAS MUST reject the request with a 400 Bad Request response.The Replaces header has specific call control semantics. If both aReplaces header field and another header field with contradictorysemantics are present in a request, the request MUST be rejected with a 400 "Bad Request" response.If the Replaces header field matches more than one dialog, the UAMUST act as if no match is found.If no match is found, the UAS rejects the INVITE and returns a 481Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog which was not created with an INVITE,the UAS MUST reject the request with a 481 response.If the Replaces header field matches a dialog which has alreadyterminated, the UA SHOULD decline the request with a 603 Declinedresponse. (If the matched invitation was just terminated, thereplacement request should fail as well. Declining the request with a 600-class response prevents an irritating race-condition where the UA rings or alerts for a replacement call which is not wanted.)If the Replaces header field matches an active dialog, the UA MUSTverify that the initiator of the new INVITE is authorized to replace the matched dialog. If the initiator of the new INVITE has beensuccessfully authenticated as equivalent to the user who is beingreplaced, then the replacement is authorized. For example, if theuser being replaced and the initiator of the replacement dialog share the same credentials for Digest authentication [6], or they sign the replacement request with S/MIME [7] with the same private key andpresent the (same) corresponding certificate used in the originaldialog, then the replacement is authorized.Alternatively, the Referred-By mechanism [4] defines a mechanism that the UAS can use to verify that a replacement request was sent onbehalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the replacement request contains a Referred-By header that corresponds to the user being replaced, theUA SHOULD treat the replacement as if the replacement was authorized by the replaced party. The Referred-By header SHOULD reference acorresponding, valid Refererred-By Authenticated Identity Body [5]. Mahy, et al. Standards Track [Page 5]The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply a different policy to the replacement dialog than was applied to the replaced dialog.In addition, the UA MAY use other authorization mechanisms definedfor this purpose in standards track extensions. Extensions coulddefine other mechanisms for transitively asserting authorization of a replacement.If authorization is successful, the UA attempts to accept the newINVITE, reassign the user interface and other resources of thematched dialog to the new INVITE, and shut down the replaced dialog. If the UA cannot accept the new INVITE (for example: it cannotestablish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave thematched dialog unchanged.If the Replaces header field matches a confirmed dialog, it checksfor the presence of the "early-only" flag in the Replaces headerfield. (This flag allows the UAC to prevent a potentiallyundesirable race condition described in Section 7.1.) If the flag is present, the UA rejects the request with a 486 Busy response.Otherwise, it accepts the new INVITE by sending a 200-class response, and shuts down the replaced dialog by sending a BYE. If the Replaces header field matches an early dialog that was initiated by the UA, it accepts the new INVITE by sending a 200-class response, and shutsdown the replaced dialog by sending a CANCEL.If the Replaces header field matches an early dialog that was notinitiated by this UA, it returns a 481 (Call/Transaction Does NotExist) response to the new INVITE, and leaves the matched dialogunchanged. Note that since Replaces matches only a single dialog,the replacement dialog will not be retargeted according to the sameforking logic as the original request which created the early dialog. (Currently, no use cases have been identified for replacing just asingle dialog in this circumstance.)4. User Agent Client Behavior: Sending a Replaces HeaderA User Agent that wishes to replace a single existing early orconfirmed dialog with a new dialog of its own, MAY send the targetUser Agent an INVITE request containing a Replaces header field. The User Agent Client (UAC) places the Call-ID, to-tag, and from-taginformation for the target dialog in a single Replaces header fieldand sends the new INVITE to the target. If the user agent onlywishes to replace an early dialog (as in the Call Pickup example inSection 7.1), the UAC MAY also include the "early-only" parameter in Mahy, et al. Standards Track [Page 6]the Replaces header field. A UAC MUST NOT send an INVITE with aReplaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field.Note that use of this mechanism does not provide a way to matchmultiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic.For example, if Alice replaces Cathy in an early dialog with Bob, but Bob does not answer, Alice’s replacement request will not match other dialogs to which Bob’s UA redirects, nor other branches to which his proxy forwards. Although this specification takes reasonableprecautions to prevent unexpected behavior in the face of forking,implementations SHOULD only address replacement requests (i.e., setthe Request-URI of the replacement request) to the SIP Contact URI of the target.5. Proxy behaviorProxy Servers do not require any new behavior to support thisextension. They simply pass the Replaces header field transparently as described in the SIP specification.Note that it is possible for a proxy (especially when forking basedon some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Replacesheader field to a completely orthogonal set of Contacts other thanthe original request it was intended to replace. In this case, theINVITE request with the Replaces header field will fail.6. Syntax6.1. The Replaces HeaderThe Replaces header field indicates that a single dialog identifiedby the header field is to be shut down and logically replaced by the incoming INVITE in which it is contained. It is a request headeronly, and defined only for INVITE requests. The Replaces headerfield MAY be encrypted as part of end-to-end encryption. Only asingle Replaces header field value may be present in a SIP request.This document adds the following entry to Table 2 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBEand NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are definedrespectively in [15], [16], [8], [17], [18], [19], and [20].Mahy, et al. Standards Track [Page 7]Header field where proxy ACK BYE CAN INV OPT REG MSG ------------ ----- ----- --- --- --- --- --- --- --- Replaces R - - - o - - -SUB NOT REF INF UPD PRA PUB --- --- --- --- --- --- --- Replaces R - - - - - - -The following syntax specification uses the augmented Backus-NaurForm (BNF) as described in RFC 2234 [3]. The syntax below relies on a number of productions from SIP [1].Replaces = "Replaces" HCOLON callid *(SEMI replaces-param) replaces-param = to-tag / from-tag / early-flag / generic-paramto-tag = "to-tag" EQUAL tokenfrom-tag = "from-tag" EQUAL tokenearly-flag = "early-only"A Replaces header field MUST contain exactly one to-tag and exactlyone from-tag, as they are required for unique dialog matching. Forcompatibility with dialogs initiated by RFC 2543 [9] compliant UAs, a tag of zero matches both tags of zero and null. A Replaces headerfield MAY contain the early-flag.Examples:Replaces: 98732@;from-tag=r33th4x0r;to-tag=ff87ffReplaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-onlyReplaces: 87134@171.161.34.23;to-tag=24796;from-tag=06.2. New Option Tag for Require and Supported HeadersThis specification defines a new Require/Supported header option tag "replaces". UAs which support the Replaces header MUST include the"replaces" option tag in a Supported header field. UAs that wantexplicit failure notification if Replaces is not supported MAYinclude the "replaces" option in a Require header field.Example:Require: replaces, 100relMahy, et al. Standards Track [Page 8]7. Usage ExamplesThe following non-normative examples are not intended to enumerateall the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see SIPService Examples [14]. Via and Max-Forwards headers are omitted for clarity and brevity.7.1. Replacing an Early Dialog at the OriginatorIn this example, Bob just arrived in the lab and hasn’t registeredthere yet. He hears his desk phone ring. He quickly logs into asoftware UA on a nearby computer. Among other things, the softwareUA has access to the dialog state of his desk phone. When it notices that his phone is ringing, it offers him the choice of taking thecall there. The software UA sends an INVITE with Replaces to Alice. When Alice’s UA receives this new INVITE, it CANCELs her originalINVITE and connects Alice to Bob.Bob BobAlice desk lab| | |*1 |-----INVITE----------->| |*2 |<----180---------------| Bob hears desk phone || | ringing from lab but || | isn’t REGISTERed yet || | || |<--fetch dialog state --|| |---response ----------->|*3/4 |<-----INVITE with Replaces/200/ACK--------------|*5/6 |------CANCEL/200------>| |*7 |<-----487--------------| ||------ACK------------->| || | || | |Message *1: Alice -> Bob’s desk phoneINVITE sip:bob@ SIP/2.0To: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:alice@>Mahy, et al. Standards Track [Page 9]Message *2: Bob’s desk phone -> AliceSIP/2.0 180 RingingTo: <sip:bob@>;tag=6472From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITEContact: <sip:bob@>Message *3: Bob in lab -> AliceINVITE sip:alice@To: <sip:alice@>From: <sip:bob@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:bob@>Replaces: 425928@;to-tag=7743;from-tag=6472;early-onlyMessage *4: Alice -> Bob in labSIP/2.0 200 OKTo: <sip:alice@>;tag=9232From: <sip:bob@>;tag=8983Call-ID: 09870@CSeq: 1 INVITEContact: <sip:alice@>Message *5: Alice -> Bob’s deskCANCEL sip:bob@ SIP/2.0To: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 CANCELContact: <sip:alice@>Message *6: Bob’s desk -> AliceSIP/2.0 200 OKTo: <sip:bob@>From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 CANCELContact: <sip:bob@>Mahy, et al. Standards Track [Page 10]Message *7: Bob’s desk -> AliceSIP/2.0 487 Request TerminatedTo: <sip:bob@>;tag=6472From: <sip:alice@>;tag=7743Call-ID: 425928@CSeq: 1 INVITE8. Security ConsiderationsThe extension specified in this document significantly changes therelative security of SIP devices. Currently in SIP, even if aneavesdropper learns the Call-ID, To, and From headers of a dialog,they cannot easily modify or destroy that dialog if Digestauthentication or end-to-end message integrity are used.This extension can be used to disconnect participants or replaceparticipants in a multimedia conversation. As such, invitations with the Replaces header MUST only be accepted if the peer requestingreplacement has been properly authenticated using a standard SIPmechanism (Digest or S/MIME), and authorized to request a replacement of the target dialog. All SIP implementations are already requiredto support Digest Authentication. In addition, implementations which support the Replaces header SHOULD also implement the Referred-Bymechanism.How a User Agent determines which requests are legitimatelyauthorized to make dialog replacements is non-trivial and depends on a considerable amount of local policy configuration. In general,there are four cases when an authorization for a replacement isreasonable or warranted.1. Replacement made by a party considered equivalent to the replaced party2. Replacement made on behalf of the replaced party (perhapstransitively)3. Replacement made by a former participant4. Replacement made by a specifically authorized partyStarting with #1 for example, if an executive and an assistant bothreceive requests for a shared address-of-record, if so configured,either should be able to replace dialogs of the other for the shared identity. Both could even share the same keying material (Digest or S/MIME), or one could hold an authorization document signed by the Mahy, et al. Standards Track [Page 11]other expressing this relationship. Likewise, in a call centerenvironment, each call center agent could possess credentials towhich supervisors also have access.The most common use case of a replacement is on the request of thereplaced participant (who no longer wants to be involved). This isthe case in many features, such as completing an Attended Transferand converting a 3-way call to a point-to-point call. Suchreplacements are typically triggered by a REFER [8] request from the replaced participant. The Referred-By [4] mechanism defines one way to identify the apparent original requester and can point to a SIPAuthenticated Identity Body [5] (an S/MIME-based signed assertion) to secure this information.In the example in section 1, Alice sends an INVITE with Replaces toBob. Alice was a former participant in the conversation and had aprevious dialog relationship with Bob. Alice can use the same Digest or S/MIME credentials she used to authenticate with Bob during theoriginal call to prove that she was a former participant. Note that this justification for replacing calls is more dangerous than theothers, and in most cases is another way to authorize that thereplacing participant is available. Implementations SHOULD NOT rely on this method as an authorization mechanism.The last scenario is the easiest to secure but the least likely to be useful in practice. It is unlikely that an arbitrary host in theInternet is aware of any special authorization relationship betweenthe replaced and the replacing parties. However, this use case maybe useful in some environments. Since this usage does noteffectively degrade the security of the solution, it is stillallowed.Some mechanisms for obtaining the dialog information needed by theReplaces header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, andnotifications after a REFER request. Since manipulating this dialog information could cause User Agents to replace the wrong dialog, use of message integrity protection for this information is STRONGLYRECOMMENDED. Use of end-to-end security mechanisms to encrypt thisinformation is also RECOMMENDED.This extension was designed to take advantage of future signature or authorization schemes defined in standards track extensions. Ingeneral, call control features benefit considerably from such work. Mahy, et al. Standards Track [Page 12]9. IANA Considerations9.1. Registration of "Replaces" SIP headerName of Header: ReplacesShort form: noneNormative description: section 6.1 of this document9.2. Registration of "replaces" SIP Option-tagName of option: replacesDescription: Support for the SIP Replaces headerSIP headers defined: ReplacesNormative description: This document10. AcknowledgmentsThanks to Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, and many other members of the SIP WG for their continued support of thecause of distributed call control in SIP.11. References11.1. Normative References[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002.[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.[4] Sparks, R., "The Session Initiation Protocol (SIP) Referred-ByMechanism", RFC 3892, September 2004.[5] Peterson, J., "The Session Initiation Protocol (SIP)Authenticated Identity Body (AIB) Format", RFC 3893, September2004.Mahy, et al. Standards Track [Page 13][6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:Basic and Digest Access Authentication", RFC 2617, June 1999.[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions(S/MIME) Version 3.1 Message Specification", RFC 3851, July2004.11.2. Informative References[8] Sparks, R., "The Session Initiation Protocol (SIP) ReferMethod", RFC 3515, April 2003.[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,"SIP: Session Initiation Protocol", RFC 2543, March 1999.[10] Mahy, R., "A Call Control and Multi-party usage framework forthe Session Initiation Protocol (SIP)", Work in Progress, March 2003.[11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) inthe Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.[12] Sparks, R. and A. Johnston, "Session Initiation Protocol CallControl - Transfer", Work in Progress, February 2003.[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated DialogEvent Package for the Session Initiation Protocol (SIP)", Workin Progress, March 2003.[14] Johnston, A. and S. Donovan, "Session Initiation ProtocolService Examples", Work in Progress, March 2003.[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., andD. Gurle, "Session Initiation Protocol (SIP) Extension forInstant Messaging", RFC 3428, December 2002.[16] Roach, A., "Session Initiation Protocol (SIP)-Specific EventNotification", RFC 3265, June 2002.[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATEMethod", RFC 3311, October 2002.Mahy, et al. Standards Track [Page 14][19] Rosenberg, J. and H. Schulzrinne, "Reliability of ProvisionalResponses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.[20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work inProgress, February 2003.12. Authors’ AddressesRohan MahyCisco Systems, Inc.5617 Scotts Valley DrScotts Valley, CA 95066USAEMail: rohan@Billy BiggsEMail: bbiggs@Rick DeanEMail: rfc@Mahy, et al. Standards Track [Page 15]13. Full Copyright StatementCopyright (C) The Internet Society (2004).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HEREPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Mahy, et al. Standards Track [Page 16]。
SSLTLS会话重放攻击防护SSL/TLS会话重放攻击防护SSL/TLS（Secure Socket Layer/Transport Layer Security）是一种常用的加密传输协议，用于保护互联网上的数据传输安全。
然而，正如所有的安全措施都有漏洞一样，SSL/TLS协议也存在一些安全威胁，其中之一就是会话重放攻击（session replay attack）。
本文将介绍SSL/TLS会话重放攻击的原理和影响，并提供一些有效的防护方法。
一、会话重放攻击原理会话重放攻击是一种被动攻击方式，攻击者通过拦截和记录SSL/TLS会话的加密数据，然后重新发送这些数据来重放会话。
攻击者可以通过拦截网络流量或对受害者发起中间人攻击来获取会话数据。
在一个成功的会话重放攻击中，攻击者重播先前捕获的有效SSL/TLS数据，目标系统会误认为这是合法的请求，从而执行相关操作。
这可能导致各种问题，例如身份盗窃、账户劫持、非法操作等。
二、会话重放攻击的危害1. 身份盗窃：攻击者可以获取合法用户的登录凭证、会话令牌等敏感信息，进而冒充用户身份进行非法操作。
2. 资金损失：如果涉及到金融交易，攻击者可以利用会话重放攻击完成支付、转账等操作，导致用户经济损失。
3. 机密信息泄露：攻击者可以拦截敏感数据的会话，例如信用卡号、密码等，从而泄露用户隐私。
4. 业务中断：会话重放攻击可导致系统或应用服务不可用，造成业务中断，影响用户体验和声誉。
三、防护措施为了有效抵御SSL/TLS会话重放攻击，以下是一些常见的防护措施：1. 加密会话数据：使用加密算法对会话数据进行加密处理，确保数据传输的机密性和完整性，使攻击者无法理解、篡改和重播会话数据。
2. 使用唯一的会话标识符：在每个会话中，使用唯一且不可预测的标识符来识别和验证会话，例如使用随机数或时间戳构建会话ID。
3. 时间戳和序列号：为会话数据设置时间戳和序列号，服务器在接收到请求时检查其有效性，拒绝处理已过期或重复的请求。
Internet Engineering Task Force (IETF) A. Niemi Request for Comments: 5839 Nokia Category: Standards Track D. Willis, Ed. ISSN: 2070-1721 Softarmor Systems May 2010 An Extension to Session Initiation Protocol (SIP) Eventsfor Conditional Event NotificationAbstractThe Session Initiation Protocol (SIP) events framework enablesreceiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating,refreshing, and terminating subscriptions, as well as fetching andperiodic polling of resource state. These procedures provide notools to avoid replaying event notifications that have already beenreceived by a user agent. This memo defines an extension to SIPevents that allows the subscriber to condition the subscriptionrequest to whether the state has changed since the previousnotification was received. When such a condition is true, either the body of a resulting event notification or the entire notificationmessage is suppressed.Status of This MemoThis is an Internet Standards Track document.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Further information onInternet Standards is available in Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5839.Niemi & Willis Standards Track [Page 1]Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Niemi & Willis Standards Track [Page 2]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 51.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 52. Motivations and Background . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 52.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 63. Overview of Operation . . . . . . . . . . . . . . . . . . . . 74. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 105. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 5.1. Detecting Support for Conditional Notification . . . . . . 13 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18 5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 185.8. Handling Transient Errors . . . . . . . . . . . . . . . . 196. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 216.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 227. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 227.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 228. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 238.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 239. Security Considerations . . . . . . . . . . . . . . . . . . . 2410. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2411. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Niemi & Willis Standards Track [Page 3]1. IntroductionThe Session Initiation Protocol (SIP) events framework provides anextensible facility for requesting notification of certain eventsfrom other SIP user agents. This framework includes procedures forcreating, refreshing, and terminating subscriptions, as well as thepossibility to fetch or periodically poll the event resource.Several instantiations of this framework, called event packages have been defined, e.g., for presence [RFC3856], message waitingindications [RFC3842], and registrations [RFC3680].By default, every SUBSCRIBE request generates a NOTIFY requestcontaining the latest event state. Typically, a SUBSCRIBE request is issued by the subscriber whenever it needs a subscription to beinstalled, periodically refreshed, or terminated. Once thesubscription has been installed, the majority of the NOTIFYsgenerated by the subscription refreshes are superfluous; thesubscriber usually is in possession of the event state already,except in the unlikely case where a state change exactly coincideswith the periodic subscription refresh. In most cases, the finalevent state generated upon terminating the subscription similarlycontains resource state that the subscriber already has.Fetching or polling of resource state behaves in a similarlysuboptimal way in cases where the state has not changed since theprevious poll occurred. In general, the problem lies with theinability to persist state across a SUBSCRIBE request.This memo defines an extension to optimize the SIP events framework. This extension allows a notifier to tag notifications (called entity- tags hereafter) and the subscriber to condition its subsequentSUBSCRIBE requests for actual changes since a notification carryingthat entity-tag was issued. The solution is similar to conditionalrequests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], and follows the mechanism already defined for the PUBLISH [RFC3903]method for issuing conditional event publications.This memo is structured as follows. Section 2 explains thebackground, motivations, and requirements for the work; Section 3gives a general overview of the mechanism; Section 4 explains theunderlying model for resources and entities as they apply toconditional notification; Section 5 defines the subscriber behavior; Section 6 defines the notifier behavior; Section 7 includes theprotocol element definitions; Section 8 includes the IANAconsiderations; and Section 9 includes the security considerations. Niemi & Willis Standards Track [Page 4]1.1. Document ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119[RFC2119] and indicate requirement levels for compliantimplementations.1.2. TerminologyIn addition to the terminology introduced in [RFC3261], [RFC3265],and [RFC3903], this specification uses these additional terms todescribe the objects of conditional notification:resourceAn object identified by a URI whose resource state can be accessed using the SIP Event Notification framework. There is a singleauthoritative notifier responsible for communicating the resource state.entityThe representation of resource state. An entity consists of thestate data carried in the body of a NOTIFY message, as well asrelated meta-data in the message header. There may be manyversions of an entity, one current and the others stale. Eachversion of an entity is identified by an entity-tag, which isguaranteed to be unique across all versions of all entities for a resource and event package.2. Motivations and Background2.1. OverviewA SUBSCRIBE request creates a subscription with a finite lifetime.This lifetime is negotiated using the Expires header field, andunless the subscription is refreshed by the subscriber before theexpiration is met, the subscription is terminated. The frequency of these subscription refreshes depends on the event package, andtypically ranges from minutes to hours.2.2. Problem DescriptionThe SIP events framework does not include different protocol methods for initiating and terminating of subscriptions, subscriptionrefreshes, and fetches inside and outside of the SIP dialog. TheSUBSCRIBE method is overloaded to perform all of these functions.The difference between a fetch that does not create a (lasting)subscription and a SUBSCRIBE that creates one is in the ExpiresNiemi & Willis Standards Track [Page 5]header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE onlygenerates a single NOTIFY, after which the subscription immediatelyterminates. Lasting subscriptions typically have relatively shortexpiry periods, requiring periodic sending of new SUBSCRIBE requests in order to refresh the subscription.Each new SUBSCRIBE request generates a NOTIFY request containing the latest resource state. Even if the state has not changed, it is sent again in response to each poll or subscription refresh. This is very similar to the HTTP [RFC2616] problem of repeated GET operations on a resource. HTTP solves the problem using conditional requests. Theserver versions each entity with an entity-tag that identifies aspecific instance of that entity. Clients making GET requests canthen include the entity-tag for the version of the entity that theybelieve to be current in an "If-None-Match" header field. The server can compare this entity-tag to the entity it believes to be currentand suppress resending the entity in the response if the serverbelieves the client’s version matches. In other words, the serverdoesn’t resend information that the client has already received.The SIP PUBLISH [RFC3903] method uses a similar mechanism, where arefresh of a publication is done by reference to its assigned entity- tag, instead of retransmitting the event state each time thepublication expiration is extended.2.3. RequirementsAs a summary, here is the required functionality to solve thepresented issues:REQ1: It must be possible to suppress the NOTIFY request (or at aminimum, the event body therein) if the subscriber is already in possession of (or has previously received and discarded)the latest event state of the resource.REQ2: This mechanism must apply to initial subscriptions in whichthe subscriber is attempting to resume an earliersubscription that has been paused.REQ3: This mechanism must apply to refreshing a subscription.REQ4: This mechanism must apply to terminating a subscription(i.e., an unsubscribe).REQ5: This mechanism must apply to fetching or polling of resource state.Niemi & Willis Standards Track [Page 6]3. Overview of OperationWhenever a subscriber initiates a subscription, it issues a SUBSCRIBE request. The SUBSCRIBE request is sent, routed, and processed by the notifier normally, i.e., according to the Session Initiation Protocol [RFC3261] and SIP-Specific Event Notification [RFC3265].If the notifier receiving the SUBSCRIBE request supports conditional subscriptions, it generates an entity-tag for the current entity, and includes it in a SIP-ETag header field of the NOTIFY request. Theentity-tag is unique across all versions of all entities for aresource and event package. See Section 4 for more on this.Entity-tags are independent of subscriptions. This allowsnotifications generated to a fetch or a poll to have valid entity-tags even across subsequent fetches or polls.The subscriber will store the entity-tag received in the notification along with the resource state. It can then later use this entity-tag to make a SUBSCRIBE contain a condition in the form of a "Suppress-If-Match" header field. Unlike the "If-Match" condition in a PUBLISH [RFC3903] request, which applies to whether the PUBLISH succeeds orreturns an error, this condition applies to the stream ofnotifications that are sent after the SUBSCRIBE request has beenprocessed.The Suppress-If-Match header field contains the last entity-tag seen by the subscriber. This condition, if true, instructs the notifierto suppress either the body of a subsequent notification, or theentire notification.The condition is evaluated by matching the value of the header field against the entity-tag of the entity that would normally be sent inthe associated NOTIFY message. There is also a wildcard entity-tagwith a special value of "*" that always matches.Niemi & Willis Standards Track [Page 7]Subscriber Notifier---------- --------(1) SUBSCRIBE -------->Expires: 3600<-------- (2) 200 (or 202)<-------- (3) NOTIFYSubscription-State: active SIP-ETag: ffee2(4) 200 -------->... time passes ...(5) SUBSCRIBE --------> \ if "ffee2"Suppress-If-Match: ffee2 | matchesExpires: 3600 | local| entity-tag|<-------- (6) 204 / then... time passes and resource state (entity) changes...<-------- (7) NOTIFYSubscription-State: active SIP-ETag: ca89a(8) 200 -------->... time passes ...(9) SUBSCRIBE --------> \ if "ca89"Suppress-If-Match: ca89a | matchesExpires: 0 | local| entity-tag|<-------- (10) 204 / thenFigure 1: Example Message FlowFigure 1 describes a typical message flow for conditionalnotification:(1) The subscriber initiates a subscription by sending a SUBSCRIBE request for a resource.Niemi & Willis Standards Track [Page 8](2) After proper authentication and authorization, the notifieraccepts the subscription.(3) The notifier then immediately sends the initial eventnotification, including a unique entity-tag in a SIP-ETagheader field.(4) The subscriber accepts the notification and stores the entity- tag value along with the resource state.(5) Later, the subscriber refreshes the subscription, and includes an entity-tag in a Suppress-If-Match header field.(6) The notifier evaluates the condition by matching its localentity-tag value for the resource against the value of theSuppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification will not be sent.(7) At some point, the state of the resource changes, e.g., thepresence status of a user changes from online to busy. Thistriggers an event notification with a new value in the SIP-ETag header field.(8) The subscriber accepts the notification and stores the newentity-tag along with the resource state.(9) After a while, the subscriber decides to terminate thesubscription. It adds a condition for Suppress-If-Match, andincludes the entity-tag it received in the previous NOTIFY.(10) The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-If-Matchheader field. If the condition evaluates to true, the notifier informs the subscriber that no notification will be sent. This concludes the subscription.The benefit of using conditional notification in this example is inthe reduction of the number of NOTIFY requests the subscriber canexpect to receive. Each event notification that the subscriber hasalready seen is suppressed by the notifier. This example illustrates only one use case for the mechanism; the same principles can be used to optimize the flow of messages related to other event notification use cases.Niemi & Willis Standards Track [Page 9]4. Resource Model for Entity-TagsThe key to understanding how conditional notification works isunderstanding the underlying resource model of event notification.In general, this model is similar to the resource model of HTTP with some key differences. This section explains in detail the model asit applies to SIP events. Figure 2 illustrates the model.+-----+............ | |. . | URI |. Represen . | |. tation . +-----+. . |*............ |. |. V. +----------+ +---------+composition | |* | Event |+------<>| Resource |----------->| Package |<----.| | | | | || +----------+ +----.----+ || /_\ ||* | classification+--------+ | || | .----------------.------’ || Entity | | | || | | | |*+--------+ +----------+ +------------+ +----------+^ | | | | | || | Presence | | Conference | | Template || | | | | | ||1..* +----------+ +------------+ +----.-----++---------+ /_\| | || Version | || | +---------++---------+ | Watcher ||1 | Info || | |V +---------++---------+| Entity- || Tag || |+---------+Figure 2: Resource Model DiagramNiemi & Willis Standards Track [Page 10]For a given event package, there is a single authoritative agentresponsible for zero or more resources. That is, even for adistributed agent, the resource state is uniform across allinstances. The resource itself can be a list of resources [RFC4662]. Conditional notification for list subscriptions is addressed inSection 6.5.A resource is identified by zero or more URIs, which can be SIP URIs, pres URIs [RFC3859], or similar. Subscribers use this URI tosubscribe to the resource for certain types of events, identified by the event package.With a successful subscription, a subscriber receives eventnotifications that communicate the resource state and the changesthereto. Each event notification carries a representation of thecurrent resource state. This representation is influenced by manyfactors, e.g., authorization and filtering rules, and the eventcomposition rules of the notifier.This representation is realized in an "entity". Each resource may be associated with zero or more entities. For example, there may bemultiple subscribers to the presence information of a single user (a resource), and each subscriber may have a different filtered view of that resource, producing one entity per subscriber. However, eachentity is associated with one and only one resource; there is no"compositing" of resources at the entity level. Resources maythemselves be made up of information from other resources (be"composite resources"), but this does not change the one-resource-per-entity rule.An entity consists of the data carried in the body of a NOTIFYmessage and related meta-data in the message header. Whenever thedata in the body or any of the meta-data changes, the notifier MUSTproduce a new entity-tag. This meta-data MUST include, but is notlimited to the following SIP header fields defined in the SessionInitiation Protocol [RFC3261] and SIP Specific Event Notification[RFC3265]:1. Content-Disposition2. Content-Encoding3. Content-Language4. Content-Length5. Content-TypeNiemi & Willis Standards Track [Page 11]6. EventNote that the Subscription-State is explicitly not part of theentity. In the future, event packages may define additional fieldsthat implementations need to consider as part of the entity.An entity has one or more versions of which only one is current andall others stale. Each version has an entity-tag, which uniquelyidentifies it across all versions of all entities pertaining to asingle resource and event package.Note that two entity-tags for different resources being equal doesnot indicate identical entities. In other words, if an entity-tagreceived for a subscription to a first resource matches an entity-tag received for a subscription to a second resource, the subscribercannot assume that the two entity values are equal.With partial event notification, the NOTIFY message only carries the delta state, or the set of changes to the previous version of theentity. In that case, implementations MUST consider the full eventstate as the version of the entity to which the entity-tag in theNOTIFY message applies.The conditional notification mechanism is independent of the way inwhich subscriptions are installed. In other words, the mechanismsupports implicit subscriptions, such as those associated with theREFER method [RFC3515].It is possible that the same resource is in some shape or formaccessible through another mechanism in addition to SIP EventNotification, e.g., HTTP or the SIP PUBLISH method. In general,implementations MUST NOT expect the entity-tags to be shared between the mechanisms, unless event packages or specific applications of SIP events explicitly define such dependencies.5. Subscriber BehaviorThis section augments the subscriber behavior defined in RFC 3265[RFC3265]. It first discusses general issues related to indicatingsupport for the mechanism (Section 5.1) and creating conditions inSUBSCRIBE requests (Section 5.2). Next, it describes subscriberbehavior for receiving NOTIFY requests (Section 5.3), and specificclient workflows for polling resource state (Section 5.4), resuming a subscription (Section 5.5), refreshing a subscription (Section 5.6), and terminating a subscription (Section 5.7). Finally, handling oftransient errors is discussed (Section 5.8).Niemi & Willis Standards Track [Page 12]5.1. Detecting Support for Conditional NotificationThe mechanism defined in this memo is backwards compatible with SIPevents [RFC3265] in that a notifier supporting this mechanism willinsert a SIP entity-tag in its NOTIFY requests, and a subscriber that understands this mechanism will know how to use it in creating aconditional request.Unaware subscribers will simply ignore the entity-tag, make requests without conditions, and receive the default treatment from thenotifier. Unaware notifiers will simply ignore the conditionalheader fields and continue normal operation.5.2. Generating SUBSCRIBE RequestsWhen creating a conditional SUBSCRIBE request, the subscriber MUSTinclude a single conditional header field including an entity-tag in the request. The condition is evaluated by comparing the entity-tag of the subscribed resource with the entity-tag carried in theconditional header field. If they match, the condition evaluates to true.Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, these conditions do not apply to the SUBSCRIBE request itself, but to the resulting NOTIFY requests. When true, the condition drives thenotifier to change its behavior with regard to sending thenotifications after the SUBSCRIBE.This specification defines a new header field called Suppress-If-Match. This header field introduces a condition to the SUBSCRIBErequest. If true, it instructs the notifier either to omit the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent within an existing dialog) or to suppress (i.e., block) the NOTIFY requestthat would otherwise be triggered by the SUBSCRIBE (for anestablished dialog). In the latter case, the SUBSCRIBE message will be answered with a 204 (No Notification) response. As long as thecondition remains true, it also instructs the notifier either tosuppress any subsequent NOTIFY request or, if there are reportablechanges in the NOTIFY header, e.g., the Subscription-State haschanged, to suppress the body of any subsequent NOTIFY request.If the condition is false, the notifier follows its default behavior. If the subscriber receives a 204 (No Notification) response to an in- dialog SUBSCRIBE, the subscriber MUST consider the event state andthe subscription state unchanged.Niemi & Willis Standards Track [Page 13]The value of the Suppress-If-Match header field is an entity-tag,which is an opaque token that the subscriber simply copies (byte-wise) from a previously received NOTIFY request. Inclusion of anentity-tag in a Suppress-If-Match header field of a SUBSCRIBE request indicates that the client has a copy of, or is capable of recreating a copy of, the entity associated with that entity-tag.Example:Suppress-If-Match: b4cf7The header field can also be wildcarded using the special "*" entity- tag value. Such a condition always evaluates to true regardless ofthe value of the current entity-tag for the resource.Example:Suppress-If-Match: *Such a wildcard condition effectively quenches a subscription; theonly notifications received are those reporting changes to thesubscription state and those in response to a SUBSCRIBE message sent outside of an existing dialog. In both cases, the notifications will not contain a body.A subscription with a wildcard Suppress-If-Match condition isuseful in scenarios where the subscriber wants to temporarily put a subscription in dormant mode. For example, a host may want toconserve bandwidth and power when it detects from screen or input device inactivity that the user isn’t actively monitoring thepresence statuses of contacts.5.3. Receiving NOTIFY RequestsWhen a subscriber receives a NOTIFY request that contains a SIP-ETag header field, it MUST store the entity-tag if it wishes to make useof the conditional notification mechanism. The subscriber MUST beprepared to receive a NOTIFY with any entity-tag value, including avalue that matches any previous value that the subscriber might have seen.The subscriber MUST NOT infer any meaning from the value of anentity-tag; specifically, the subscriber MUST NOT assume identicalentities (i.e., event state) for NOTIFYs with identical entity-tagvalues when those NOTIFYs result from subscription to differentresources.Niemi & Willis Standards Track [Page 14]Note that there are valid cases for which identical entity-tagvalues on different resources may occur. For example, it ispossible to generate entity-tag values using a one-way hashfunction, resulting in the possibility that two differentresources having the same entity-value will also have the sameentity-tag. Clients however MUST NOT assume that this is thecase, as the algorithm for the generation of entity-tags isnotifier-dependent and not negotiated with the subscriber.Consequently, the subscriber cannot differentiate between twoentity-tags that have the same value because they are similarhashes of identical entities, or because two notifiers happen tohave used the same sequential number as an entity-tag. Entitytags are only required to be unique for a given resource, notglobally unique.5.4. Polling or Fetching Resource StatePolling with conditional notification allows a user agent toefficiently poll resource state. This is accomplished using theSuppress-If-Match condition:Niemi & Willis Standards Track [Page 15]。
