Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19

Hi Hannes,

The expanded authorization paragraph is very clear to me, thanks.

Regarding protection of the RESERVE` and RESPONSE` hop-by-hop security:

>> Don't interior nodes protect RESERVE` and RESPONSE` messages using  
>> hop-by-hop security, or is that just  RESERVE and RESPONSE  
>> messages? It seems like that would be a simple measure to  mitigate  
>> threats (4) and (5).
>>
> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind  
> that for these two messages the "hop" are ingress and egress; for  
> the interior nodes these messages cannot be modified.

Thanks for the clarification of what constitutes a "hop". So if I  
understand correctly, only Ingress and Egress routers share a security  
association for protecting RESERVE and RESPONSE messages.

> Using hop-by-hop security for RESERVE` and RESPONSE` messages does  
> not help since the adversary model assumes that one of the interior  
> nodes is acting maliciously.
>
> Does this make sense to you?

My point was that transport security of RESERVE` and RESPONSE`  
messages between Interior nodes would also be helpful to protect each  
Interior node from on-path attackers between themselves. I assume they  
may have adversaries between them.

But I think I understand now that the Security Considerations section  
is written assuming that only Ingress and Egress devices participate  
in any kind of security association. You're not trusting the Interior  
nodes at all, so they themselves have no security considerations.  
Could you please clarify the following points in the INTRODUCTION,  
which would make that clearer?
- What is a "hop" with respect to security associations
- The security of RMD-QOSM does not depend on interior nodes. (It does  
say "The focus on intra-domain QoS signaling simplifies trust  
management and reduces overall complexity." but that's doesn't really  
go far enough.)
- Because the security of RMD-QOSM does not depend on interior nodes,  
protection of RESERVE` and RESPONSE` messages is not specified.

Thanks,
Brian

On May 5, 2010, at 11:18 AM, Hannes Tschofenig wrote:

> Hi Brian,
>
> thanks for the quick response.
>
> Brian Weis wrote:
>> Hi Hannes,
>>
>> On May 1, 2010, at 4:02 AM, Hannes Tschofenig wrote:
>>
>>> Hey Brian,
>>>
>>> thanks for your detailed review.
>>>
>>> I have updated the security consideration section based on your  
>>> comments. I have added text to describe security threats in more  
>>> detail, discuss what the assumptions are (trust model), provide  
>>> security requirements, and updated the part that talks about the  
>>> specific solution mechanisms.
>>
>> Thanks! Your re-written security considerations section is very  
>> much improved. I do have a couple of comments/questions inline below.
>>
>>>
>>> I also added a sentence about the authorization aspect you  
>>> mentioned. There is nothing special about RMD that would require  
>>> additional description beyond what is covered in the QoS NSLP and  
>>> the solutions we had worked on in the context of the Diameter QoS  
>>> application. The authorizatoin aspect largely happens before RMD  
>>> signaling is actually triggered.
>>>
>>> My proposed text can be found below (before Georgios adds it to  
>>> the draft itself).
>>>
>>> Ciao
>>> Hannes
>>>
>>> ---------------
>>>
>>>
>>> 5. Security Considerations
>>>
>>> I. INTRODUCTION
>>>
>>> A design goal of the RMD-QOSM protocol is to be "lightweight" in  
>>> terms
>>> of the number of exchanged signaling message and the amount of state
>>> established at involved signaling nodes (with and without reduced
>>> state operation). A side-effect of this design decision is to  
>>> introduce
>>> second-class signaling nodes, namely QNE Interior nodes, that are  
>>> restricted
>>> in their ability to perform QoS signaling actions. Only the QNE  
>>> Ingress and
>>> the QNE Egress nodes are allowed to initiate certain signaling  
>>> messages.
>>> Moreover, RMD focuses on an intra-domain deployment only.
>>>
>>> The above description has the following implications for security:
>>>
>>> 1) QNE Ingress and QNE Egress nodes require more security and  
>>> fault protection
>>> than QNE Interior nodes because their uncontrolled behavior has  
>>> larger
>>> implications for the overall stability of the network.
>>>
>>> 2) The focus on intra-domain QoS signaling simplifies trust  
>>> management and
>>> reduces overall complexity. See Section 2 of RFC 4081 for a more  
>>> detailed
>>> discussion about the complete set of communication models  
>>> available for
>>> end-to-end QoS signaling protocols.
>>>
>>> It is important to highlight that RMD always uses the message  
>>> exchange
>>> shown in Figure 24
>>> even if there is no end-to-end signaling session. If the RMD-QOSM is
>>> triggered based on an E2E signaling exchange then the RESERVE  
>>> message
>>> is created by a node outside the RMD domain and will subsequently
>>> travel further on (e.g., to the data receiver). Such an exchange is
>>> shown in Figure 3. As such, an evaluation of RMD's security
>>> always has to be seen as a combination of the two signaling  
>>> sessions, (1)
>>> and (2) of Figure 24.
>>>
>>> QNE QNE QNE QNE
>>> Ingress Interior Interior Egress
>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful
>>> | | | |
>>> | RESERVE (1) | | |
>>> +--------------------------------------------->|
>>> | RESERVE` (2) | | |
>>> +-------------->| | |
>>> | | RESERVE` | |
>>> | +-------------->| |
>>> | | | RESERVE` |
>>> | | +------------->|
>>> | | | RESPONSE` (2)|
>>> |<---------------------------------------------+
>>> | | | RESPONSE (1) |
>>> |<---------------------------------------------+
>>>
>>> Figure 24: RMD Message Exchange.
>>>
>>> Authorizing quality of service reservations is accomplished
>>> using the AAA framework and the functionality is inherited from
>>> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp],
>>> and not described again in this document. As a technical
>>> solution mechanism Diameter QoS application
>>> [I-D.ietf-dime-diameter-qos] may be used.
>>
>> I assume that it is implied that this authorization is done by the  
>> Ingress router, as opposed to each Interior node in the path. It  
>> would be helpful to say this.
>
> That's true. I extended the paragraph to:
>
> "
> Authorizing quality of service reservations is accomplished
> using the AAA framework and the functionality is inherited from
> the underlying NSIS QoS NSLP, see [I-D.ietf-nsis-qos-nslp],
> and not described again in this document. As a technical
> solution mechanism Diameter QoS application
> [I-D.ietf-dime-diameter-qos] may be used. The end-to-end
> reservation request arriving at the ingress node will
> trigger the authorization procedure with the backend AAA
> infrastructure. The end-to-end reservation is typically
> triggered by a human interaction with a software application,
> such as a voice-over-IP client when making a call. When
> authorization is successful then no further user initiated
> QoS authorization check is expected to be performed within
> the RMD domain for the intra-domain reservation.
> "
>
>>
>>>
>>>
>>> II. SECURITY THREATS
>>>
>>> In the RMD-QOSM, the ingress node constructs both end-to-
>>> end and intra-domain signaling messages based on the
>>> end-to-end message initiated by the sender end node. The
>>> Interior nodes within the RMD network ignore the end-to-end
>>> signaling message, but process, modify, and forward the intra-domain
>>> signaling messages towards the egress node. In the
>>> meantime, resource reservation states are installed, modified
>>> or deleted at each interior node along the data path according
>>> to the content of each intra-domain signaling message. The
>>> edge nodes of an RMD network are critical components
>>> that require strong security protection. Therefore, they act
>>> as security gateways for incoming and outgoing signaling
>>> messages. Moreover, a certain degree of trust has to be placed
>>> into Interior nodes within the RMD-QOSM network, such that
>>> these nodes can perform signaling message processing and
>>> take the necessary actions.
>>>
>>> With the RMD-QOSM we assume that the
>>> ingress and the egress nodes are not controlled by an adversary
>>> and the communication between the ingress and the egress
>>> nodes is secured using standard GIST security mechanisms
>>
>> Is there a reference for these security mechanisms?
>>
> I added a reference to the security consideration section of GIST  
> (Section 6 of [I-D.ietf-nsis-ntlp])..
>
>>> and experiences integrity, replay and confidentiality protection.
>>> Note that this only affects messages directly addressed by
>>> these two nodes and not any other message that needs to
>>> be processed by intermediaries. The SESSION ID object
>>> of the end-to-end communication is visible, via GIST, to the
>>> Interior nodes.
>>> In order to define the security threats that are associated
>>> with the RMD-QOSM we consider that an adversary that may be located
>>> inside the RMD domain and could
>>> drop, delay, duplicate, inject, or modify signaling packets.
>>> Depending on location of adversary, we speak about an on-path
>>> adversary or an off-path adversary, see also RFC 4081 [RFC4081].
>>>
>>>
>>> II-A. On-path Adversary
>>>
>>> The on-path adversary is a node, which supports RMD-QOSM
>>> and is able to observe RMD-QOSM signaling message
>>> exchanges.
>>>
>>> 1) Dropping signaling messages
>>>
>>> An adversary could drop any signaling messages after
>>> receiving them. This will cause a failure of reservation
>>> request for new sessions or deletion of resource units
>>> (bandwidth) for on-going sessions due to states timeout.
>>> It may trigger the ingress node to retransmit the
>>> lost signaling messages. In this scenario the adversary
>>> drops selected signaling messages, for example intra-domain reserve
>>> messages. In the RMD-QOSM, the retransmission
>>> mechanism can be provided at the ingress node
>>> to make sure that signaling messages can reach the
>>> egress node. However, the retransmissions triggered by
>>> the adversary dropping messages may cause certain
>>> problems. Therefore, it is recommended to disable the use
>>> of retransmissions in the RMD-QOSM aware network.
>>>
>>> 2) Delaying Signaling Messages
>>>
>>> Any signaling message could be delayed by an adversary.
>>> For example, if RESERVE` messages
>>> are delayed over the duration of the refresh period then the  
>>> resource units
>>> (bandwidth) reserved along the nodes for corresponding
>>> sessions will be removed. In this situation, the ingress
>>> node does not receive the RESPONSE within a certain
>>> period, and considers that the signaling message is
>>> failed, which may cause a retransmission of the ’failed’
>>> message. The egress node may distinguish between the
>>> two messages, i.e., the delayed message and the retransmitted
>>> message, and it could take a proper response.
>>> However, interior nodes suffer from this retransmission
>>> and they may reserve twice the resource units (bandwidth)
>>> requested by the ingress node.
>>
>> Can this threat be generalized from "twice" to "N times", if the  
>> message is retransmitted N times?
>> If so, it seems like a serious threat. Can the mitigation for  
>> Replayed Signaling Messages (i.e., storing values) be used here.  
>> Actually, from the description a retransmitted signaling message  
>> seems indistinguishable from a replayed signaling message.
>>
> For interior nodes it is not possible to distinguish replays. The  
> only entities that detect the replays are edge devices. So, my  
> proposal is to let the egress detect and to alert about the  
> potential problem.
>
>
>>>
>>> 3) Replaying Signaling Messages
>>>
>>> An adversary may want to replay signaling messages.
>>> It first stores the
>>> received messages and decides when to replay these
>>> message and at what rate (packets/per seconds).
>>> When the RESERVE` message
>>> carried a RII object, the egress will reply with a
>>> RESPONSE` message towards the ingress node. The ingress
>>> node can then detect replays by comparing the value of
>>> RII in the RESPONSE` messages with the stored value.
>>>
>>> 4) Injecting Signaling Messages
>>>
>>> Similar to the replay-attack scenario, the adversary may
>>> store a part of the information carried by signaling
>>> messages, for example, the RSN object. When the
>>> adversary injects signaling messages, it puts the stored
>>> information together with its own generated parameters
>>> (Bandwidth, RII, etc.) into the injected messages and
>>> then sends them out. Interior nodes will process these
>>> messages by default, reserve the requested resource units
>>> (bandwidth) and pass them to downstream nodes. It
>>> may happen that the resource units (bandwidth) on the
>>> Interior nodes are exhausted if these injected messages
>>> consume much bandwidth.
>>>
>>> 5) Modifying Signaling Messages
>>>
>>> On-path adversaries are capable of modifying any part
>>> of the signaling message. For example, the adversary
>>> can modify the <M>, <S> and <Overload %> parameters
>>> of the RMD-QSPEC messages. The egress node
>>> will then use the SESSION ID and subsequently the
>>> BOUND SESSION ID objects to refer to that flow
>>> to be terminated or set to lower priority. It is also
>>> possible for the adversary to modify the <Bandwidth>
>>> and/or <PHB Class> parameter, which could cause
>>> a modification of an amount of the requested resource
>>> units (bandwidth) changes.
>>
>> Don't interior nodes protect RESERVE` and RESPONSE` messages using  
>> hop-by-hop security, or is that just  RESERVE and RESPONSE  
>> messages? It seems like that would be a simple measure to  mitigate  
>> threats (4) and (5).
>>
> RESERVE and RESPONSE messages use hop-by-hop security. Keep in mind  
> that for these two messages the "hop" are ingress and egress; for  
> the interior nodes these messages cannot be modified.
>
> Using hop-by-hop security for RESERVE` and RESPONSE` messages does  
> not help since the adversary model assumes that one of the interior  
> nodes is acting maliciously.
>
> Does this make sense to you?
>
>>> II-B. Off-path Adversary
>>>
>>> In this case the adversary is not located on-path and it
>>> does not participate in the exchange of RMD-QOSM signaling
>>> messages, and therefore is unable to eavesdrop signaling
>>> messages. Hence, the adversary does not know valid RIIs,
>>> RSNs, SESSION IDs. Hence, the adversary has to generate
>>> new parameters and constructs new signaling messages. Since
>>> Interior nodes operate in reduced state mode,
>>> injected signaling messages are treated as new once, which
>>> causes Interior nodes to allocate additional reservation state.
>>>
>>>
>>> III. SECURITY REQUIREMENTS
>>>
>>> The following security requirements are set as goals for the
>>> intra-domain communication, namely:
>>>
>>> * Nodes, which are never supposed to participate in the NSIS  
>>> signaling
>>> exchange, must not interfere with QNE Interior nodes. Off-path
>>> nodes (off-path with regard to the path taken by a particular
>>> signaling message exchange) must not be able to interfere with
>>> other on-path signaling nodes.
>>>
>>> * The actions allowed by a QNE Interior node should be minimal  
>>> (i.e.,
>>> only those specified by the RMD-QOSM). For example, only the QNE
>>> Ingress and the QNE Egress nodes are allowed to initiate certain
>>> signaling messages. QNE Interior nodes are, for example, allowed to
>>> modify certain signaling message payloads.
>>>
>>> Note that the term `interfere` refers to all sorts of security
>>> threats, such as denial of service, spoofing, replay, signaling
>>> message injection, etc.
>>>
>>> III. SECURITY MECHANISMS
>>
>> Nit: should be "IV."
> Yup.
>
>>
>>>
>>> An important security mechanism that was
>>> built into RMD-QOSM was the ability to tie the end-to-end
>>> RESERVE and the RESERVE` messages
>>> together using the BOUND SESSION ID and to allow the
>>> ingress node to match the RESERVE`
>>> with the RESPONSE` by using the
>>> RII. These mechanisms enable the edge nodes to detect unexpected
>>> signaling messages.
>>>
>>> We assume that the RESERVE/RESPONSE is sent with hop-by-hop
>>> channel security provided by GIST and protected between the QNE
>>> Ingress and the QNE Egress.
>>
>> If the RESERVE/RESPONSE messages are protected hop-by-hop, why  
>> can't RESERVE`/RESPONSE` messages? Or does hop-by-hop mean that  
>> only the ingress and egress devices are "hops" and share keys?
>>
> See response above.
>
> Ciao
> Hannes
>
>> Thanks,
>> Brian
>>
>>> GIST security mechanisms MUST be used
>>> to offer authentication,
>>> integrity, and replay protection. Furthermore, encryption MUST be  
>>> used
>>> to
>>> prevent an adversary located along the path of the RESERVE
>>> message to learn information about the session that can later be  
>>> used
>>> to inject a RESERVE` message.
>>>
>>> The following messages need to be mapped to
>>> each other to make sure that the occurrence of one message is not
>>> without the other one:
>>>
>>> a) the RESERVE and the RESERVE` relate to each other at the QNE
>>> Egress and
>>>
>>> b) the RESPONSE and the RESERVE relate to each other at the QNE
>>> Ingress and
>>>
>>> c) the RESERVE` and the RESPONSE` relate to each other. The RII is
>>> carried in the RESERVE` message and the RESPONSE` message that is
>>> generated by the QNE Egress node contains the same RII as the
>>> RESERVE`. The RII can be used by the QNE Ingress to match the
>>> RESERVE` with the RESPONSE`. The QNE Egress is able to determine
>>> whether the RESERVE` was created by the QNE Ingress node since the
>>> intra-domain session, which sent the RESERVE`, is bound to an end- 
>>> to-
>>> end session via the BOUND_SESSION_ID value included in the intra-
>>> domain QoS-NSLP operational state maintained at the QNE Egress.
>>>
>>> The RESERVE and the RESERVE` message are tied together using the
>>> BOUND_SESSION_ID(s) maintained by the intra-domain and end-to-end
>>> QoS-NSLP operational states maintained at the QNE edges, see Section
>>> 4.3.1, 4.3.2, 4.3.3. Hence, there cannot be a RESERVE` without a
>>> corresponding RESERVE. The SESSION_ID can fulfill this purpose quite
>>> well if the aim is to provide protection against off-path  
>>> adversaries
>>> that do not see the SESSION_ID carried in the RESERVE and the
>>> RESERVE` messages.
>>>
>>> If, however, the path changes (due to re-routing or due to mobility)
>>> then an adversary could inject RESERVE` messages (with a previously
>>> seen SESSION_ID) and could potentially cause harm.
>>>
>>> An off-path adversary can, of course, create RESERVE` messages that
>>> cause intermediate nodes to create some state (and cause other
>>> actions) but the message would finally hit the QNE Egress node. The
>>> QNE Egress node would then be able to determine that there is
>>> something going wrong and generate an error message.
>>>
>>> The severe congestion handling can be triggered by intermediate  
>>> nodes
>>> (unlike other messages). In many cases, however, intermediate nodes
>>> experiencing congestion use refresh messages modify the <S> and
>>> <O> parameters of the message. These messages are still
>>> initiated by the QNE Ingress node and carry the SESSION_ID. The QNE
>>> Egress node will use the SESSION_ID and subsequently the
>>> BOUND_SESSION_ID, maintained by the intra-domain QoS-NSLP  
>>> operational
>>> state, to refer to a flow that might be terminated. The
>>> aspect of intermediate nodes initiating messages for severe
>>> congestion handling is for further study.
>>>
>>> QNE Ingress QNE Interior QNE Interior QNE Egress
>>> NTLP stateful NTLP stateless NTLP stateless NTLP stateful
>>> | | | |
>>> | REFRESH RESERVE` | |
>>> +-------------->| REFRESH RESERVE` |
>>> | (+RII) +-------------->| REFRESH RESERVE`
>>> | | (+RII) +------------->|
>>> | | | (+RII) |
>>> | | | |
>>> | | | REFRESH |
>>> | | | RESPONSE`|
>>> |<---------------------------------------------+
>>> | | | (+RII) |
>>>
>>> Figure 25: RMD REFRESH message exchange
>>>
>>> During the refresh procedure a RESERVE` creates a RESPONSE`, see
>>> Figure 25. The RII is carried in the RESERVE` message and the
>>> RESPONSE` message that is generated by the QNE Egress node contains
>>> the same RII as the RESERVE`.
>>>
>>> The RII can be used by the QNE Ingress to match the RESERVE` with  
>>> the
>>> RESPONSE`.
>>>
>>> A further aspect is marking of data traffic. Data packets can be
>>> modified by an intermediary without any relationship to a signaling
>>> session (and a SESSION_ID). The problem appears if an off-path
>>> adversary injects spoofed data packets.
>>>
>>>
>>> The adversary thereby needs to spoof data packets that relate to the
>>> flow identifier of an existing end-to-end reservation that SHOULD be
>>> terminated. Therefore the question arises how an off-path adversary
>>> SHOULD create a data packet that matches an existing flow identifier
>>> (if a 5-tuple is used). Hence, this might not turn out to be simple
>>> for an adversary unless we assume the previously mentioned
>>> mobility/re-routing case where the path through the network changes
>>> and the set of nodes that are along a path changes over time.
>>>
>>>
>>>
>>>
>>> Brian Weis wrote:
>>>> I have reviewed this document as part of the security  
>>>> directorate's ongoing effort to review all IETF documents being  
>>>> processed by the IESG. These comments were written primarily for  
>>>> the benefit of the security area directors. Document editors and  
>>>> WG chairs should treat these comments just like any other last  
>>>> call comments.
>>>>
>>>> This document describes an NSIS QoS Model for networks that use  
>>>> the Resource Management in Diffserv (RMD) concept. It describes  
>>>> RMD-QOSM, which are new payloads sent using the GISP signaling  
>>>> mechanism, where the new payloads request or reserve resources. A  
>>>> number of data flows are discussed, depending on whether nodes  
>>>> within a network boundary participate in the protocol or not.
>>>>
>>>> The Security Considerations section covers the following topics:
>>>> - Byzantine adversaries (i.e., participants taken over by an  
>>>> adversary) are a general problem, but this section intends to  
>>>> discuss additional threats as a result of the new protocol. There  
>>>> is an extensive discussion of on-path and off-path adversaries,  
>>>> which seems to intend to be addressing Byzantine adversaries.
>>>> - RMD-QOSM is claimed to be lightweight, with different routers  
>>>> allowed certain operations dependant on the role a router plays  
>>>> in the system. E.g., only Ingress/Egress nodes are allowed to  
>>>> initiate certain signaling messages.
>>>> - RMD-QOSM "relies on the security support that is provided by  
>>>> the bounded end-to-end session, which is running between the  
>>>> boundaries of the RMD domain", but doesn't mandate that security  
>>>> support.
>>>>
>>>> The existing text is helpful, but not sufficient. The following  
>>>> points are suggestions to improve this section.
>>>>
>>>> 1. The statement at the beginning of Security Considerations  
>>>> discusses adversaries taking over a router, but the new threats  
>>>> are not very clear. Are the authors considering that security  
>>>> associations are revealed, that reservation data routed to a  
>>>> particular router can be changed or forged, or something else?
>>>>
>>>> 2. The trust model used by RMD-QOSM is hinted at in the  
>>>> discussion of on-path and off-path adversaries, but a discussion  
>>>> of exactly what devices are trusted and what they're trusted to  
>>>> do would be helpful. For example, is every interior router in the  
>>>> network is trusted to handle any particular RESERVE or RESERVE`  
>>>> message? If not, then how are the paths setup so that only  
>>>> authorized routers will see a particular message? On the other  
>>>> hand, if routing is used to route the messages then it would seem  
>>>> that any router must be authorized to handle messages happened to  
>>>> be routed to them -- but then it isn't clear that there can be a  
>>>> difference between an "on-path" and "off-path" adversary.
>>>>
>>>> 3. Another dimension of trust model is the fact that ingress/ 
>>>> egress routers seem to trust each other more than they trust  
>>>> interior nodes. This seems evidenced by the fact that RESERVE  
>>>> messages (Figure 24) don't seem to be intended to be modified by  
>>>> the interior routers. In the case of probes, I would expect that  
>>>> this would be especially important, but probes do not seem to be  
>>>> specifically discussed in this section.
>>>>
>>>> 4. There don't seem to be any actual security requirements or  
>>>> recommendations made on GIST messaging. As such, it isn't clear  
>>>> that attackers that have not taken over a participant (i.e., a  
>>>> man in the middle) are in any way foiled. I would expect to see  
>>>> more MUSTs and SHOULDs in this section regarding message  
>>>> security. There are statements in the I-D such as "In the  
>>>> situation a security association exists" and "If we assume that  
>>>> the RESERVE/RESPONSE is sent with hop-by-hop channel security".  
>>>> There should be some description of the threats to the messaging  
>>>> by a non-participant, and stating what available mechanisms MUST  
>>>> or SHOULD be used.
>>>>
>>>> 5. Since roles seem to be an important part of the security  
>>>> considerations, it would be helpful to see discussion of the  
>>>> different threats & requirements on the ingress/egress routers  
>>>> and the internal routers in their different roles.
>>>>
>>>> 6. An important service of RMD-QOSM is admission control, but  
>>>> there doesn't seem to be any discussion of how the ingress  
>>>> routers determine whether or not reservation requests given to  
>>>> them are valid. I would have thought that is of particular  
>>>> importance, but if it's considered out of scope this section  
>>>> might mention that fact.
>>>
>>>>
>>>> Hope that helps,
>>>> Brian
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>
>>
>>
>

-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com