Subject: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Jan 2008 15:14:51 +0100

Hi,

At the meeting "Applicability of Keying Methods for RSVP Security"
(draft-behringer-tsvwg-rsvp-security-groupkeying-01) was presented. It 
seemed to be quite a lot of support for having TSVWG develop an 
Informative document on RSVP Group keying. Thus the question to the WG 
is; Should TSVWG adopt 
draft-behringer-tsvwg-rsvp-security-groupkeying-01 as an basis for a WG 
item?

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 24 Jan 2008 15:57:56 +0100

Magnus,

I support making this a WG document.

Francois

On 23 Jan 2008, at 15:14, Magnus Westerlund wrote:

> (draft-behringer-tsvwg-rsvp-security-groupkeying-01) was presented.  
> It seemed to be quite a lot of support for having TSVWG develop an  
> Informative document on RSVP Group keying. Thus the question to the  
> WG is; Should TSVWG adopt draft-behringer-tsvwg-rsvp-security- 
> groupkeying-01 as an basis for a WG item?
>
> Best Regards
>
> Magnus Westerlund
>

---

From: "Kantawala, Anshul" <[email-masked]>
Date: Thu, 24 Jan 2008 10:21:48 -0500

Hi,
I support making this draft a WG document.

Anshul Kantawala

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 9:15 AM
To: tsvwg
Subject: [Tsvwg] Adopting
draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?

Hi,

Best Regards

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jan 2008 19:04:20 +0200

(individual hat on)

I'm not convinced that this document needs to be a TSVWG document.  
It's an Informational document that surveys group keying options for  
RSVP, and as such could be published directly through the RFC Editor.

Lars

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 28 Jan 2008 10:59:31 +0100

Hi Lars and all,

On 24 Jan 2008, at 18:04, Lars Eggert wrote:

> It's an Informational document that surveys group keying options  
> for RSVP, and as such could be published directly through the RFC  
> Editor.

I am not aware of any solution currently available from the IETF to  
actually deploy such distribution of group keys for RSVP.
This could, for example, be easily achieved with small extensions to  
GDOI (draft-weis-gdoi-for-rsvp), but a solution will only be defined  
in IETF (e.g. by MSEC) if the corresponding need is established by  
the TSVWG.
So, my recommendation is that TSVWG decides whether group keying is  
useful for RSVP security or not, and if yes documents this decision.  
Making draft-behringer-tsvwg-.. a WG document seems a natural way to  
achieve this.
This is one reason why I feel draft-behringer-tsvwg should be  
considered for WG document.

(I certainly feel that a group keying solution for RSVP would be very  
useful. If some people feel that group keying for RSVP is not useful,  
it would be interesting to know why and how the problems solved by  
group keying can be addressed differently.)

Another practical reason is that the issue of group keying methods  
for RSVP gets raised by Security experts every time there is a new  
RSVP-related document going to IESG Last Call. See, for example, the  
thread with Ran Atkinson from Dec 2006 and titled "Re: [Tsvwg] Re:  
IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec".
Effectively, on request from Security experts in order to make sure  
the security aspects are covered appropriately, we end up re- 
discussing the applicability of existing keying methods +  
applicability of potential future group keying methods in the  
"Security Considerations" section of every RSVP-related document (see  
RFC4860, draft-ietf-tsvwg-emergency-rsvp). It is important that  
applicability/Pros&cons of various keying methods for RSVP be  
documented by TSVWG once for all. This discussion should reflect the  
view of the WG since it affects RSVP security across all RSVP-related  
documents.

Also, draft-behringer-tsvwg proposes to document applicability of  
keying methods to IPsec protection of RSVP (as opposed to just RSVP  
authentication). We are not aware of an IETF document where this is  
well addressed and feel this would be useful (and has been requested  
by a few people e.g. Anshul from LMCO).

Cheers

Francois

---

From: Lars Eggert <[email-masked]>
Date: Mon, 28 Jan 2008 12:26:02 +0200

Hi,

> in IETF (e.g. by MSEC) if the corresponding need is established by  

based on the discussions in Vancouver, I thought the goal of this  
document was to survey the options for group keying for RSVP. I don't  
see how such a survey would motivate the need for any sort of solution  
work. Meaning that even if this survey finds that none of the existing  
options are always satisfactory, that's a finding that to me still  
doesn't immediately motivate the need to develop any new solution. New  
protocol work should be motivated by an application requiring it.

> considered for WG document.

For which current work item in TSVWG would group keying be useful, or  
rather, required? A need for a new solution needs to come from an  
application that requires group keying. As far as I know, no such  
application is being worked on in TSVWG.

> (I certainly feel that a group keying solution for RSVP would be  
> very useful. If some people feel that group keying for RSVP is not  
> useful, it would be interesting to know why and how the problems  
> solved by group keying can be addressed differently.)

Lots of things are useful - what application requires group keying for  
RSVP that goes beyond what we currently have? I'd like to understand  
where the motivation comes from.

> "Security Considerations" section of every RSVP-related document  
> (see RFC4860, draft-ietf-tsvwg-emergency-rsvp). It is important that  
> view of the WG since it affects RSVP security across all RSVP- 
> related documents.

So this argues for extracting the repeated argument into an individual  
draft, so it can be referenced instead of needing to be duplicated.  
But it does not motivate the need for a new solution.

> by a few people e.g. Anshul from LMCO).

Can you point me at Anhul's email, please? I couldn't dig it up locally.

Thanks,
Lars

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 12:59:09 +0200

Hi Magnus, 

There are two facets to your question: 

First, I believe that there is an issue that needs to be solved when it
comes to key management with RSVP. The document discusses various
aspects although I believe that a number of changes probably need to be
made. This can, however, be covered as part of the standard working
group procedures. 

Second, I am not sure what the implications of adopting this document
are. For example, does it mean that the group then has to go for the
solution described in [I-D.weis-gdoi-for-rsvp]?

I support item 1 but I am not so sure about item 2.

Ciao
Hannes

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: 23 January, 2008 16:15
To: tsvwg
Subject: [Tsvwg] Adopting
draft-behringer-tsvwg-rsvp-security-groupkeying asWG item?

Hi,

Best Regards

Magnus Westerlund

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Jan 2008 07:23:27 -0500

> in IETF (e.g. by MSEC) if the corresponding need is established by

I'd like to add that there's some pent-up pool of
GDOI profiles, at least one member of which is waiting
to see what happens with the RSVP profile and what MSEC
decides to do.

I do think that this is an enormously useful approach
for when peers cannot be known in advance and PKI is
unavailable or otherwise not attractive.

Melinda

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jan 2008 14:31:11 +0200

Hi Melinda,

> unavailable or otherwise not attractive.
How many other alternatives have you considered?

Btw, since a IKE DOI builds on IKE there might well be a PKI underneath.

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Jan 2008 07:42:27 -0500

> How many other alternatives have you considered?

There weren't a lot of reasonable alternatives available.  For
us, a primary attraction is that group keys provide an
implicit authorization, which might not be as fine-grained
as we might like in an ideal world but goes beyond what's
available with other tools while doing it simply (no manual
keying, no Kerberos).  This is particularly useful for
keying a protocol which can carry multiple application-
types or to multiple communities inside the same administrative
domain.

> Btw, since a IKE DOI builds on IKE there might well be a PKI underneath.

Sure, but it's not the 'I' we're trying to avoid.

At any rate, I think it would be good if someone from TSVWG and
someone from MSEC sat down and hashed out how they'd like the
work to go forward, then brought the proposal to both groups.
It feels like this has been stalled out for awhile.

Melinda

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Jan 2008 14:23:10 +0100

> I support item 1 but I am not so sure about item 2.

Hannes, what I can read from the above, I would say neither. The call 
for WG item is intended to have zero standards track work. Only document 
what exist and and possibly what major holes that exist where clear need 
has been expressed.

Cheers

Magnus Westerlund

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 08:47:15 -0500

>> for RSVP, and as such could be published directly through the RFC  

Lars,
     Are you *objecting* to the document becoming a TSV WG
informational document xor merely observing that multiple
options on handling the draft exist in theory ?

> actually deploy such distribution of group keys for RSVP.

Agreed.

> considered for WG document.

That all sounds reasonable to me.

> solved by group keying can be addressed differently.)

Agreed.

> view of the WG since it affects RSVP security across all RSVP- 

Fundamental Facts of RSVP Insecurity:
--------------------------------------
- RSVP is a control protocol.  RSVP messages, if accepted by routers
   or other devices, can/will modify network behaviour in meaningful
   ways.
- Unauthenticated control protocols can always be used by attackers
   to cause unintended outcomes within deployed networks.  See
   [Bellovin89] for numerous real-world Internet examples of this.
- RSVP has an (unused) cryptographic authentication mechanism,
   but has no published approach for automated key management with
   that mechanism.
- Virtually no networks are entirely private these days; virtually
   all deployed networks are either directly or indirectly (e.g. via
   some security appliance or filtering IP router) connected to the
   Internet.  I know of several cases where an organisation erroneously
   thought it had a private network, only to discover later that there
   actually was indirect connectivity to the public Internet
   (e.g. a dual-homed host with IP routing disabled -- attackers
   broke into that host via its public IP address, then used the
   box to subvert the supposedly private network.)
- In the case of RSVP, it is NOT generally knowable in advance which
   path a flow or reservation might take, since the path changes
   over time due to dynamic routing, fibre cuts, and so forth.
- In turn, this means that no manual keying strategy for RSVP
   Authentication exists that is practical to deploy or use.
- The effect of the above is that RSVP is not safe to deploy in
   nearly all scenarios, because there is no way to protect against
   forged (or modified in transit) RSVP control traffic.
   (Actually, I cannot immediately think of any safe RSVP deployment
   that is possible at present outside of a private network with
   an Air-Gap Firewall, but maybe I've overlooked some obscure
   case.)

This is a very serious problem for anyone who wants to see RSVP
more widely deployed and used.

Caveat: The above analysis is intra-domain.  The inter-domain
         situation of RSVP is much more dire from a security
         perspective.

RSVP's situation is somewhat different from that of an IGP:
------------------------------------------------------------
- In the case of an interior routing protocol (e.g. RIPv2), the
   scope of the deployment is limited to a single administrative
   domain AND (importantly) that administrative domain knows a priori
   who all of the legitimate RIPv2 participants are, where they
   are located topologically, and has full administrative control
   over the configuration of those devices.
- So for an IGP, while multicast group keying (e.g. MSEC) is
   strongly desirable, it is entirely practical to pre-provision
   a shared secret (i.e. key).  So a network operator (e.g. university)
   can enable RIPv2 Cryptographic Authentication to protect
   against passive attacks [RFC-1704].
- A serious limitation of that manual keying approach is that
   it is difficult to rekey the routing system.  At present, the
   best hope is that one has a fully automated router configuration
   system that would let one provision a new key in place via
   the router configuration/provisioning system (i.e. somewhat
   out of band).
- All that said, I would VERY MUCH like to see a suitable GDOI
   be created for each of (RIPv2, RIPng, OSPFv2, OSPFv3).  At one
   time, I had started work on an OSPF DOI for ISAKMP.  However,
   at that time, there was no underlying group keying mechanism;
   all of the above routing protocols use multicast, not unicast,
   so group keying is a requirement.  I'd be quite happy to review
   and comment on such a draft if it existed.  I am not an expert
   on MSEC, but IGP rekeying sounds like it should be a good fit
   for MSEC's capabilities.

RSVP's situation is somewhat different from BGP:
------------------------------------------------
- All BGP sessions are pair-wise, with both parties
   being known in advance.  There is nothing automatic
   about bringing up new BGP peers on a router.  It
   requires manual intervention in all cases.
- So this is different from RSVP in two ways so far.
   First, the BGP sessions are unicast.  Second, both
   peers are manually configured, hence known a priori.
- For now, BGP authentication does not exist per se.
   Instead, there is a TCP Authentication Option designed
   by Andy Heffernan.  "BGP Authentication" really means
   enabling TCP Authentication for a given TCP session
   between a fixed pair of BGP peers.
- Because it is unicast, and well-known a priori, it
   is entirely practical to deploy this without automated
   key management.
- As above with the IGPs, the main key management
   problem with TCP Authentication is that there is no
   really good way to change the TCP Authentication
   session keys over time.  As with IGPs, the best chance
   is if a fully automated router configuration management
   system is in use.
- Oh, and as with the IGPs, it would be nice if someone
   would write up a TCP Authentication DOI for ISAKMP/IKE.
   That should be straight-forward to do since it is
   an ordinary unicast TCP session (so no need for MSEC).

> by a few people e.g. Anshul from LMCO).

Agreed on all points.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 08:52:03 -0500

On  28 Jan 2008, at 05:26, Lars Eggert wrote:
> For which current work item in TSVWG would group keying be useful,  
> or rather, required? A need for a new solution needs to come from an  

Group keying for RSVP is needed for EVERY existing and planned
deployment of RSVP.  Deploying RSVP without authentication is
operationally extremely risky and vulnerable -- and always has been.

So I'd say that *every* application needs it.

> So this argues for extracting the repeated argument into an
> individual draft, so it can be referenced instead of needing
> to be duplicated. But it does not motivate the need for a new
> solution.

I would prefer that the IETF not play Ostrich (a desert bird
that when attacked sticks its head under the sand rather
than fleeing the attacker).  Simply documenting that any use
of RSVP is a huge security risk seems insufficient when
practical approaches to reducing that risk appear to exist.

RSVP is completely insecure at present.  We do NOT have any
solution for key management of RSVP.  Now, we do have an
opportunity here to significantly reduce the security risks
of using RSVP by enabling a first practical approach to RSVP
key management to be created.

That alone ought to be plenty of motivation.

Yours,

Ran
[email-masked]

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 28 Jan 2008 14:53:58 +0100

Hi Lars,

We feel that there are some holes in existing key management  
approaches for RSVP. For example, existing key management cannot be  
used when the RSVP router does not know the next RSVP router. This  
situation occurs in the presence of non-RSVP-routers and is becoming  
more and more common with RSVP Aggregation approaches (e.g. RFC3175 &  
RFC4860 when used with dynamic Deaggregator discovery, RSVP over PCN  
clouds,...). Maybe this is what you would call "TSVWG applications"  
requiring some solution.

We also feel that TSVWG should address this: at least documenting the  
holes, but also ideally facilitating development of a solution.

Would you agree with these statements?

We can discuss later whether draft-behringer is the right vehicle to  
address this, whether we should restructure it or wether we should  
tackle the problem completely differently.

Thanks

Francois

On 28 Jan 2008, at 11:26, Lars Eggert wrote:

>>> I'm not convinced that this document needs to be a TSVWG  
>>> document. It's an Informational document that surveys group  
>>> keying options for RSVP, and as such could be published directly  
>>> through the RFC Editor.
>>
>> I am not aware of any solution currently available from the IETF  
>> to actually deploy such distribution of group keys for RSVP.
>> This could, for example, be easily achieved with small extensions  
>> to GDOI (draft-weis-gdoi-for-rsvp), but a solution will only be  
>> defined in IETF (e.g. by MSEC) if the corresponding need is  
>> established by the TSVWG.
>
> document was to survey the options for group keying for RSVP. I  
> don't see how such a survey would motivate the need for any sort of  
> solution work. Meaning that even if this survey finds that none of  
> the existing options are always satisfactory, that's a finding that  
> to me still doesn't immediately motivate the need to develop any  
> new solution. New protocol work should be motivated by an  
> application requiring it.
>
>> So, my recommendation is that TSVWG decides whether group keying  
>> is useful for RSVP security or not, and if yes documents this  
>> decision. Making draft-behringer-tsvwg-.. a WG document seems a  
>> natural way to achieve this.
> or rather, required? A need for a new solution needs to come from  
> an application that requires group keying. As far as I know, no  
> such application is being worked on in TSVWG.
>
> Lots of things are useful - what application requires group keying  
> for RSVP that goes beyond what we currently have? I'd like to  
> understand where the motivation comes from.
>
>> RSVP-related document going to IESG Last Call. See, for example,  
>> the thread with Ran Atkinson from Dec 2006 and titled "Re: [Tsvwg]  
>> Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec".
>> Effectively, on request from Security experts in order to make  
>> sure the security aspects are covered appropriately, we end up re- 
>> (see RFC4860, draft-ietf-tsvwg-emergency-rsvp). It is important  
>> that applicability/Pros&cons of various keying methods for RSVP be  
>> documented by TSVWG once for all. This discussion should reflect  
>> the view of the WG since it affects RSVP security across all RSVP- 
>> related documents.
>
> individual draft, so it can be referenced instead of needing to be  
> duplicated. But it does not motivate the need for a new solution.
>
>> keying methods to IPsec protection of RSVP (as opposed to just  
>> RSVP authentication). We are not aware of an IETF document where  
>> this is well addressed and feel this would be useful (and has been  
>> requested by a few people e.g. Anshul from LMCO).
>
>

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 08:54:52 -0500

> How many other alternatives have you considered?

I am not aware of any alternatives that would enable
scalable automated key management for RSVP.  At present,
there are zero standardised mechanisms for that purpose.

> Btw, since a IKE DOI builds on IKE there might well be a PKI  

ISAKMP/IKE do not require a PKI.  In fact, many deployments
of ISAKMP/IKE with IPsec today do not use any sort of PKI.
(I use one quite regularly myself.)

So nothing on the table here would require a PKI or prohibit
use of a PKI.  In short, PKIs are not germane to the thread
at hand in any way obvious to me.

Yours,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 08:57:16 -0500

On  28 Jan 2008, at 08:53, Francois Le Faucheur IMAP wrote:
> approaches for RSVP.

In fact, I am not aware of *any* practical key management
approaches for RSVP at present.

If someone thinks they have one that works when all the
participants along the dynamic RSVP path are not knowable
a priori, which is the normal case with RSVP use, please do
share. :-)

Yours,

Ran Atkinson
[email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 28 Jan 2008 15:02:26 +0100

Hi Ran, 

> there are zero standardised mechanisms for that purpose.

A standardized key management solution for RSVP being already available
we wouldn't have this discussion here. 

I wanted to challenge the statement that there is no better way than the
RSVP DOI when no other mechanisms have been considered nor proposed. 

To some extend this reminds me to the Mobile IPv6 discussion where folks
came up with the idea to use IPsec to secure Mobile IPv6 signaling. At
the end folks had to realize the security solution is 10x more complex
than the mobility protocol and it would have probably been simpler to
add mobility support to the security protocol rather than the other way
around. 
 
> (I use one quite regularly myself.)

IKE does not mandate a PKI, I know that. That's why I wrote "might". 
It depends on the deployment. 

> at hand in any way obvious to me.

Btw, I did not start the PKI discussion. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 28 Jan 2008 15:07:28 +0100

Hi Ran, 

> operationally extremely risky and vulnerable -- and always has been.

I agree that the lack of automated key management in RSVP and this fact
is know for many years already. 
So far, nobody really cared. Hence, I would like to understand the
current RSVP (not RSVP-TE) deployment a bit better.
I am still looking around for the operator that deploys it. Maybe you
can help me. Where is the RSVP deployment happening? 

Ciao
Hannes

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 10:54:10 -0500

On  28 Jan 2008, at 09:02, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> A standardized key management solution for RSVP being already
> available we wouldn't have this discussion here.
>
> I wanted to challenge the statement that there is no better way
> than the RSVP DOI when no other mechanisms have been considered
> nor proposed.

I'm quite happy to be educated that there is some other method
to be considered.  If someone has one, it would certainly be good
to put that on the table so folks could mull that over.

So far, email seen by me hasn't outlined any other possible method
for managinge RSVP key material than using MSEC with some GDOI
(whether those are RSVP Auth keys or IPsec keys for RSVP is a
separate question from using MSEC with some GDOI, so far as I am aware).

> add mobility support to the security protocol rather than the other  

Hmm, well, nothing I've said has said or implied using IPsec
or not using it.  Key management protocols ought to be modular
enough to work with various security/application protocols,
not just one.  ISAKMP/IKE is (or at least was) modular in
the right ways.  One imagines MSEC also is.

A historic process curiousity was putting IKE/ISAKMP inside
the IPsec WG, even though the resulting key management
protocol could be used with any unicast/pair-wise protocol
that needed key material.

Conveniently, and not accidentally, IKE/ISAKMP has the IPsec-unique
portion inside the separate IPsec DoI specification.  So one
can use IKE/ISAKMP to manage keys for non-IPsec protocols,
just by adding a new DOI document for the new target protocol(s).

One imagines that MSEC also could be used to manage keys for
non-IPsec protocols by adding new GDOI(s) for the new protocol(s)
(e.g. RSVP's built-in Authentication, which currently lacks any
reasonable way to manage keys OR IPsec OR both).

[Caution: I'm not an expert on MSEC, so I can't make a definitive
statement either way about MSEC in this regard.]

In any event, my understanding from the various surprise emails
this morning was that the question on the table was not to
select a particular technology approach, but instead for TSV WG
to agree to sponsor a particular Informational status I-D that
discusses the unresolved problems with key management for RSVP
and why they are needed.

So selecting a technology approach does not seem to be a question
currently in front of folks here.

Maybe I'm confused in some further way due to not being active
in TSV WG and having been surprised by this whole thread when
I read mail this morning.  If so, apologies, but nothing I could
have done to prevent that confusion, since I was drafted, rather
than volunteering for this thread.

Cheers,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2008 11:08:55 -0500

On  28 Jan 2008, at 09:07, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> I agree that the lack of automated key management in RSVP and
> this fact is know for many years already.
> So far, nobody really cared. Hence, I would like to understand
> the current RSVP (not RSVP-TE) deployment a bit better.
> I am still looking around for the operator that deploys it.
> Maybe you can help me. Where is the RSVP deployment happening?

Most ISP/academic/commercial operators I know refuse to deploy
RSVP **BECAUSE** the RSVP authentication situation is so dire.

I am aware that at least one other firm has various sorts of
RSVP applications that they have promoted to various users.
Many of these (prospective) uses are documented in the RFCs
mentioned by other folks earlier in this thread.

There are clearly some uses of RSVP in relation to MPLS that
are deployed.  I thought that was generally understood.  Some
folks use LDP instead, while others use RSVP.  RSVP-TE uses the
RSVP protocol and so has the same fundamental security issues
that other uses of RSVP have.  I would not consider RSVP
separately from RSVP-TE -- if looking from a security perspective.

[LDP is a different matter because it is a different protocol,
not because it is necessarily better from a security perspective.]

So I'd suggest that the issue is not that "nobody really cared",
but instead that people "really do care" and that this unresolved
security issue in turn has diminished the probability of RSVP
becoming more widely deployed going forward.

As to specific deployments (of ANY usage of RSVP, including but
not limited to RSVP-TE) that I've heard of, my employer routinely
has NDAs with all of our customers that prohibit me from naming
names on nearly anything -- unless the customer has specifically
granted me permission to identify them publicly.  So if one wants
names of users, I regret that I am unable to help with that.

Cheers,

Ran
[email-masked]

(DISCLAIMER: I work in research, so I tend to be out of touch
with what capabilities are/aren't in our products.  I have not
checked recently, but as of several years ago, my employer had
not shipped RSVP in any then-available product.  Of course,
I do often hear about users entire deployments, not just the
bits with our products when I am talking with users.  This is
just a standard disclaimer.)

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 28 Jan 2008 17:13:13 +0100

Hi Hannes,

> I support item 1 but I am not so sure about item 2.

draft-behringer-tsvwg discusses group keying in general and only  
mentions the specific solution of draft-weis-gdoi-for-rsvp as an  
example of solution that could be used. So it is really about item 1  
and not 2.

It would be good to hear about other potential solutions though (so  
the applicability discussions takes this into account).

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 28 Jan 2008 17:28:23 +0100

>> Maybe you can help me. Where is the RSVP deployment happening?

Many deployments in SP space with RSVP-TE (more often for Fast  
Reroute), of course.
A number of large enterprises have also deployed RSVP in their networks.
Some Government projects are considering RSVP as a component technology.

A convenient automated key management will help some of those secure  
the deployment further as well as facilitate future deployments.

Cheers

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 28 Jan 2008 17:30:29 +0100

PS: I wish Michael Behringer could jump in with his views but he is  
blissfully enjoying paternity leave.  Happy him!

On 28 Jan 2008, at 17:13, Francois Le Faucheur IMAP wrote:

> example of solution that could be used. So it is really about item  
> 1 and not 2.
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Jan 2008 12:05:08 +0200

Hi, Brian,

On 2008-1-28, at 19:58, ext Brian Weis wrote:
> Calling draft-behringer-tsvwg a "survey" of "group keying for RSVP"  
> isn't an entirely accurate statement. It's a much more fundamental  
> description of RSVP security: it documents the RSVP trust model  
> (perhaps for the first time), and from there it describes the  
> appropriate uses for RSVP keys that should be used within different  
> network topologies, as well as provisioning methods for those keys.  
> Although these topics don't motivate new TSVWG protocol development,  
> taking ownership of these RSVP security fundamentals is important  
> for TSVWG. I believe that is a good rationale for accepting draft- 
> behringer-tsvwg as a WG item.

I agree with you, and I said during the Vancouver meeting that I'd see  
such an Informational document in scope for TSVWG.

However, I'm now hesitating, because I've heard the argument being  
made (both in Vancouver during SAAG and in the recent email by  
Francois) that the acceptance of draft-behringer-tsvwg-rsvp-security- 
groupkeying as a TSVWG work item would establish a need to work on a  
solution in MSEC (based on draft-weis-gdoi-for-rsvp). I don't agree  
with this argument. At best, the document would identify a hole in the  
solution space, and if MSEC wants to fill that, I'd need to find its  
own motivation for doing so.

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Jan 2008 11:53:22 +0100

Lars Eggert skrev:
>> taking ownership of these RSVP security fundamentals is important for 
>> TSVWG. I believe that is a good rationale for accepting 
>> draft-behringer-tsvwg as a WG item.
> 
> However, I'm now hesitating, because I've heard the argument being made 
> (both in Vancouver during SAAG and in the recent email by Francois) that 
> the acceptance of draft-behringer-tsvwg-rsvp-security-groupkeying as a 
> TSVWG work item would establish a need to work on a solution in MSEC 
> (based on draft-weis-gdoi-for-rsvp). I don't agree with this argument. 
> At best, the document would identify a hole in the solution space, and 
> if MSEC wants to fill that, I'd need to find its own motivation for 
> doing so.
> 

To be clear, any solutions work, even if need is clearly identified in a 
TSVWG document would still require the chartering somewhere in the IETF. 
And for doing chartering this may in addition require a BOF to discuss 
if this is suitable work. I would please request that anyone jumps to 
conclusions by doing this document.

Cheers

Magnus Westerlund

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 29 Jan 2008 12:07:27 +0100

On 29 Jan 2008, at 11:05, Lars Eggert wrote:

>> Calling draft-behringer-tsvwg a "survey" of "group keying for  
>> RSVP" isn't an entirely accurate statement. It's a much more  
>> fundamental description of RSVP security: it documents the RSVP  
>> trust model (perhaps for the first time), and from there it  
>> describes the appropriate uses for RSVP keys that should be used  
>> within different network topologies, as well as provisioning  
>> methods for those keys. Although these topics don't motivate new  
>> TSVWG protocol development, taking ownership of these RSVP  
>> security fundamentals is important for TSVWG. I believe that is a  
>> good rationale for accepting draft-behringer-tsvwg as a WG item.
>
> I agree with you, and I said during the Vancouver meeting that I'd  
> see such an Informational document in scope for TSVWG.

Good.

> Francois) that the acceptance of draft-behringer-tsvwg-rsvp- 
> security-groupkeying as a TSVWG work item would establish a need to  
> work on a solution in MSEC (based on draft-weis-gdoi-for-rsvp). I  
> don't agree with this argument. At best, the document would  
> identify a hole in the solution space, and if MSEC wants to fill  
> that, I'd need to find its own motivation for doing so.

I am failing to see the concern.

First, I have already clarified several times that draft-behringer is  
NOT tied to draft-weis-gdoi-for-rsvp. It only mentions draft-weis- 
gdoi-for-rsvp as an example of solution to achieve automated key  
management for RSVP. The discussion in draft-behringer is about group  
keying and not about the specifics of how it is achieved. If there is  
text that ties teh discussion to draft-weis-gdoi, please identify it  
and we can fix that.

Second, draft-behringer is not proposing to dictate what MSEC should  
or should not do. It is about documenting group keying applicability  
to RSVP and its benefits in some scenarios. The expectation is indeed  
that MSEC will find its own motivation to develop a solution based on  
the benefits it would bring to RSVP. That's all.

With these clarifications in mind, do you still see an issue?
If so, perhaps you could identify the specifics parts of draft- 
behringer that create problem and we could edit/remove those parts?

The one question I do have is whether someone can think of other  
approaches than group keying for RSVP? This is because draft- 
behringer currently discusses group keying, but it could also discuss  
other approaches if there are other candidates automated key  
management approaches for RSVP.

Thanks

Francois

---

From: Brian Weis <[email-masked]>
Date: Mon, 28 Jan 2008 09:58:47 -0800

Hi Lars,

TSVWG. I believe that is a good rationale for accepting draft- 

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Kantawala, Anshul" <[email-masked]>
Date: Tue, 29 Jan 2008 11:47:03 -0500

Lars,
My comment about the usefulness of having a single IETF document that
covers all aspects of RSVP security (authentication and encryption) was
made at the Vancouver IETF meeting (name mistakenly put in as "Andrew"
in the meeting minutes: "*Andrew - interested in RSVP authentication and
RSVP over IPsec, and thinks this work should progress").

A big stumbling block we have encountered in trying to propose RSVP
signaling as a solution for government and other corporate
secure/sensitive networks is RSVP security.  Having an IETF document
covering RSVP security not only helps in handling such concerns, it will
also aid in focused development of security solutions for RSVP.

Thus, I reiterate my support in making this a WG document.

Regards,
Anshul 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Monday, January 28, 2008 5:26 AM
To: ext Francois Le Faucheur IMAP
Cc: ext Magnus Westerlund; RJ Atkinson; Brian Weis; tsvwg list IETF
Subject: Re: [Tsvwg] Adopting

Hi,

Thanks,
Lars

---

From: Brian Weis <[email-masked]>
Date: Tue, 29 Jan 2008 09:25:46 -0800

Hi Lars,

> that, I'd need to find its own motivation for doing so.

I certainly agree that the action of TSVWG accepting draft-behringer- 
tsvwg-rsvp-security-groupkeying as a WG document can't dictate any  
particular action to MSEC. But such a TWVWG document describing a  
group security model for RSVP does provide MSEC with the basis for  
considering protocol work that increases the overall level of  
security when group keys are used.

On the other hand, rejecting it sends a message to MSEC that the use  
of group security isn't particularly valuable for RSVP and so there  
isn't much point in doing addition protocol work to make the group  
security model more secure.

Thanks,
Brian

---

From: ken carlberg <[email-masked]>
Date: Tue, 29 Jan 2008 13:15:35 -0500

> security model more secure.

i think that's reading to much into the original question of whether  
the document should be a working group item or an individual submission.

my feeling is that part of the on-line discussion has drifted away  
from a more fundamental question of whether or not the draft document  
is one that requires _group_ consensus.  Put another way, do the  
authors feel the perspectives/issues brought up on this thread foster  
a need to add or change existing text?  Or, do the authors (chairs, or  
others) feel that the document speaks for itself and can be sidelined  
and weakened by issues raised by others?  if the former, then it  
should be a wg item.  if the latter, then it should stay as an  
individual submission.  And keep in mind, an individual submission is  
still constructive and reference point for the community.

My personal opinion is that the document would benefit from consensus  
input given the points raised by others on this thread.  But if the  
authors feel changes will dilute the current points made in the  
document, then it should stay an individual submission.

-ken

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 29 Jan 2008 22:20:16 +0100

Hi Ken,

On 29 Jan 2008, at 19:15, ken carlberg wrote:

>> On the other hand, rejecting it sends a message to MSEC that the  
>> use of group security isn't particularly valuable for RSVP and so  
>> there isn't much point in doing addition protocol work to make the  
>> group security model more secure.
>
> i think that's reading to much into the original question of  
> whether the document should be a working group item or an  
> individual submission.
>
> from a more fundamental question of whether or not the draft  
> document is one that requires _group_ consensus.  Put another way,  
> do the authors feel the perspectives/issues brought up on this  
> thread foster a need to add or change existing text?  Or, do the  
> authors (chairs, or others) feel that the document speaks for  
> itself and can be sidelined and weakened by issues raised by  
> others?  if the former, then it should be a wg item.  if the  
> latter, then it should stay as an individual submission.  And keep  
> in mind, an individual submission is still constructive and  
> reference point for the community.
>
> My personal opinion is that the document would benefit from  
> consensus input given the points raised by others on this thread.

Agreed.

For what it's worth, (at least) one of the authors feels:
	- that the topic of draft-behringer applicability of keying methods  
to RSVP is a significant aspect of RSVP security, and
	- that in turn, RSVP security is an important topic and a  
responsibility of the TSVWG,
	- and therefore, discussion of keying method applicability should  
reflect WG views and not just a few individuals view
	- If the document needs to be amended to reflect other WG members,  
this is a good thing

Francois

> But if the authors feel changes will dilute the current points made  
> in the document, then it should stay an individual submission.
>
> -ken
>
>
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 30 Jan 2008 07:59:54 +0100

I believe that the document should become a working group item. 
The side discussions we had were more about the next step that happens after the analysis (namely about the solution details).

I will try my best to post some comments for draft-behringer-tsvwg-rsvp-security-groupkeying either during this week or beginning of next week. 

Ciao
Hannes
  
> -----Ursprüngliche Nachricht-----
> Von: ext ken carlberg [mailto:[email-masked]] 
> Gesendet: Dienstag, 29. Januar 2008 20:16
> An: Brian Weis
> Cc: ext Magnus Westerlund; RJ Atkinson; tsvwg list IETF
> Betreff: Re: [Tsvwg] Adopting 
> draft-behringer-tsvwg-rsvp-security-groupkeyingas WG item?
> 
> 
> document  
> consensus

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Jan 2008 09:12:22 +0200

Hi Anshul,

> RSVP over IPsec, and thinks this work should progress").
draft-behringer-tsvwg-rsvp-security-groupkeying is certainly not the 
document that covers all aspects of RSVP security.

> also aid in focused development of security solutions for RSVP.
Have you ever read RFC 4230?

Please tell me more about corporate networks using RSVP todo QoS. I 
would like to met that company that deploys RSVP to dynamically signal 
QoS in their network.

Btw, when you make use of QoS mechanisms in a network then you 
automatically introduce more security vulnerabilities.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Jan 2008 09:20:51 +0200

I think that the scope of the document should be the following:

* Describe what the problem is (largely known already)
* Describe the deployment scenarios where this is a problem (not every 
possible deployment combination of RSVP is really useful in the 
real-world; in fact I would even argue the other way around). In some 
other groups in the Transport Area Lars and Magnus have been very keen 
on investigating whether there is a relevance for deployment....
* Illustrate the requirements and assumptions for solutions for the 
deployment scenarios that are seen as relevant.

If it only motivates a specific solution proposal then you could just 
merge it with the solution and use it as a motivation section for the 
solution spec.

Ciao
Hannes

Brian Weis wrote:
>>> for TSVWG. I believe that is a good rationale for accepting 
>> Francois) that the acceptance of 
>> draft-behringer-tsvwg-rsvp-security-groupkeying as a TSVWG work item 
>> would establish a need to work on a solution in MSEC (based on 
>> draft-weis-gdoi-for-rsvp). I don't agree with this argument. At best, 
>> the document would identify a hole in the solution space, and if MSEC 
>> wants to fill that, I'd need to find its own motivation for doing so.
>
> I certainly agree that the action of TSVWG accepting 
> draft-behringer-tsvwg-rsvp-security-groupkeying as a WG document can't 
> dictate any particular action to MSEC. But such a TWVWG document 
> describing a group security model for RSVP does provide MSEC with the 
> basis for considering protocol work that increases the overall level 
> of security when group keys are used.
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jan 2008 15:57:41 +0200

> options on handling the draft exist in theory ?

The latter - I'm not convinced it needs to become a TSVWG document,  
but I also don't see a reason for it not to, *if* we're clear that  
this adoption does not motivate or request and solutions work elsewhere.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jan 2008 16:08:53 +0200

Hi,

On 2008-1-29, at 13:07, ext Francois Le Faucheur IMAP wrote:
> First, I have already clarified several times that draft-behringer  
> is NOT tied to draft-weis-gdoi-for-rsvp.

I'm happy to hear you say that, because in an earlier email you said:

"I am not aware of any solution currently available from the IETF to  
actually deploy such distribution of group keys for RSVP. This could,  
for example, be easily achieved with small extensions to GDOI (draft- 
weis-gdoi-for-rsvp), but a solution will only be defined in IETF (e.g.  
by MSEC) if the corresponding need is established by the TSVWG."

The last part ("if the corresponding need is established by TSVWG")  
made me wonder whether the adoption of draft-behringer by TSVWG would  
be claimed to establish this need. I'm glad we agree that it wouldn't.

> to RSVP and its benefits in some scenarios. The expectation is  
> indeed that MSEC will find its own motivation to develop a solution  
> based on the benefits it would bring to RSVP. That's all.

Great. Because recalling the discussion in SAAG, I came away with a  
different impression. The SAAG minutes say:

"There was progress on four [MSEC - ed.] work items, including crypto  
suites for
GDOI, and extensions to GDOI for hash agility, GDOI for SRTP, and
TESLA extensions.  There are also several current work items that
are not making progress and may need to be dropped.  Some new work
has been proposed to support keying for transport and routing
protocols, but this work will not go forward unless it is clear that
the appropriate WGs in transport and routing have consensus.
If clear direction is provided, msec will consider a charter update for
new work.  Otherwise, msec will stay on course to complete its active  
documents and shut down."

The "support keying for transport" bit was about RSVP group keying  
(draft-weis), and the half-sentence following it makes it pretty clear  
that MSEC won't take it on unless TSVWG would indicate some sort of  
consensus about this work. I'm merely attempting to clarify that any  
adoption of draft-behringer isn't such an indication.

> With these clarifications in mind, do you still see an issue?

No, with these clarifications, I don't see an issue.

Lars

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 16:06:02 +0100

Hi Lars,

On 30 Jan 2008, at 15:08, Lars Eggert wrote:
>
>> Second, draft-behringer is not proposing to dictate what MSEC  
>> should or should not do. It is about documenting group keying  
>> applicability to RSVP and its benefits in some scenarios. The  
>> expectation is indeed that MSEC will find its own motivation to  
>> develop a solution based on the benefits it would bring to RSVP.  
>> That's all.
>
> "There was progress on four [MSEC - ed.] work items, including  
> crypto suites for
> new work.  Otherwise, msec will stay on course to complete its  
> active documents and shut down."
>
> (draft-weis), and the half-sentence following it makes it pretty  
> clear that MSEC won't take it on unless TSVWG would indicate some  
> sort of consensus about this work. I'm merely attempting to clarify  
> that any adoption of draft-behringer isn't such an indication.
>

Why is it so important to ensure that the TSVWG does not send any  
indication to MSEC that it would be useful to deploy a group keying  
solution for RSVP?
Is this because you know of better solutions to achieve automated key  
management for RSVP?
If yes, can you share them so that we can discuss those?
If not, what exactly would be so bad if TSVWG was to document the  
fact that group keying would be useful for RSVP and if MSEC was to  
interpret that as a cue to develop a solution for it?

Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 16:22:30 +0100

Hi Hannes,

On 30 Jan 2008, at 08:12, Hannes Tschofenig wrote:

> draft-behringer-tsvwg-rsvp-security-groupkeying is certainly not  
> the document that covers all aspects of RSVP security.

The context of this discussion was that draft-behringer plans to  
cover keying not just for RSVP Authentication but also for RSVP  
encryption. So I personally interpreted the statement of  "all  
aspects of RSVP" as "all aspects of RSVP in the dimension of which  
protection to apply to RSVP".

In any case, as far as relative scope of draft-behringer vs RFC4230,  
our earlier agreement was that draft-behringer would focus on key  
management and would refer to RFC4230 for all other aspects. The text  
of draft-behringer-..01 already states so. I assume we are still fine  
with this break down.

Cheers

Francois

> would like to met that company that deploys RSVP to dynamically  
> signal QoS in their network.
>
>> From: Lars Eggert [mailto:[email-masked]] Sent: Monday,  
>> January 28, 2008 5:26 AM
>>>> keying options  for RSVP, and as such could be published  
>>>> directly through the RFC  Editor.
>>>>
>> don't  see how such a survey would motivate the need for any sort  
>> of solution  work. Meaning that even if this survey finds that  
>> none of the existing  options are always satisfactory, that's a  
>> finding that to me still  doesn't immediately motivate the need to  
>> develop any new solution. New  protocol work should be motivated  
>> by an application requiring it.
>>
>>
>>> very useful. If some people feel that group keying for RSVP is  
>>> not  useful, it would be interesting to know why and how the  
>>> problems  solved by group keying can be addressed differently.)
>>>
>>
>>> Another practical reason is that the issue of group keying  
>>> methods  for RSVP gets raised by Security experts every time  
>>> there is a new  RSVP-related document going to IESG Last Call.  
>>> See, for example, the  thread with Ran Atkinson from Dec 2006 and  
>>> titled "Re: [Tsvwg] Re:  IETF LC comments on draft-ietf-tsvwg- 
>>> rsvp-ipsec".
>>> sure  the security aspects are covered appropriately, we end up  
>>> re- discussing the applicability of existing keying methods +   
>>> that  applicability/Pros&cons of various keying methods for RSVP  
>>> be  documented by TSVWG once for all. This discussion should  
>>> reflect the  view of the WG since it affects RSVP security across  
>>> all RSVP- related documents.
>>>
>>
>> individual  draft, so it can be referenced instead of needing to  
>> be duplicated.  But it does not motivate the need for a new solution.
>>
>>
>>> Also, draft-behringer-tsvwg proposes to document applicability  
>>> of  keying methods to IPsec protection of RSVP (as opposed to  
>>> just RSVP  authentication). We are not aware of an IETF document  
>>> where this is  well addressed and feel this would be useful (and  
>>> has been requested  by a few people e.g. Anshul from LMCO).
>>>
>>
>>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jan 2008 17:30:09 +0200

> indication to MSEC that it would be useful to deploy a group keying  

A successful consensus call to adopt draft-behringer with the goal of  
publishing it as an Informational RFC simply does not have the side  
effect of indicating to MSEC or anyone else that TSVWG recommends  
draft-weis.

Lars

> Is this because you know of better solutions to achieve automated  
> key management for RSVP?

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 30 Jan 2008 19:32:10 +0100

On 30 Jan 2008, at 16:30, Lars Eggert wrote:

>> indication to MSEC that it would be useful to deploy a group  
>> keying solution for RSVP?
>
> A successful consensus call to adopt draft-behringer with the goal  
> of publishing it as an Informational RFC simply does not have the  
> side effect of indicating to MSEC or anyone else that TSVWG  
> recommends draft-weis.

I think we have already clearly established (and re-established and  
re-re-established) that "draft-behringer is NOT tied to draft-weis- 
gdoi-for-rsvp", so I assume in the above you meant "that TSVWG  
recommends use of group keying for RSVP" (instead of "that TSVWG  
recommends use of draft-weis").

But I think I got you, this time.
It is not that you are saying that TSVWG should not influence MSEC,  
but rather you are pointing out that as per IETF procedures,  
publishing an Informational Track document (even as WG document) does  
not have the official weight to influence MSEC (and therefore should  
not be understood/expected to do so).
Is this right?

Thanks

Francois

---

From: Lars Eggert <[email-masked]>
Date: Thu, 31 Jan 2008 17:14:48 +0200

On 2008-1-30, at 20:32, ext Francois Le Faucheur IMAP wrote:
> publishing an Informational Track document (even as WG document)  
> does not have the official weight to influence MSEC (and therefore  
> should not be understood/expected to do so).
> Is this right?

Yes. An informational RFC that surveys the solution space does just  
that.

If it comes with a TSVWG consensus behind it, it establishes that  
TSVWG is of the opinion that the characterization of the solution  
space in the RFC is correct (rather than just representing the  
authors' opinion, as an individual submission with the RFC Editor  
would.)

MSEC or some other WG is free to refer to that RFC to help them decide  
which option in the solution space is most applicable to their  
particular use case, of course. But an Informational RFC can't  
recommend one solution as the TSVWG-preferred approach, especially if  
that approach isn't an Internet standard.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 31 Jan 2008 17:23:33 +0200

> security when group keys are used.

Agreed. MSEC (or any other WG) is free to take the contents of that  
RFC into account when determining which solution options best fit  
their use case.

> security model more secure.

Drafts fail to see WG adoption all the time, for all sorts of reasons.  
I don't think that if draft-behringer would fail to see TSVWG adoption  
this conclusion could be drawn from that decision.

For example, a perfectly valid reason to not adopt an Informational- 
RFC-to-be would be for the WG to agree that adoption wouldn't improve  
the document much, and that WG cycles would be better spent elsewhere.  
This is approximately what happened with draft-sarolahti-tsvwg- 
crosslayer, which is a survey not too unlike draft-behringer.

Lars

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 31 Jan 2008 20:18:27 +0100

On 31 Jan 2008, at 16:14, Lars Eggert wrote:

>> It is not that you are saying that TSVWG should not influence  
>> MSEC, but rather you are pointing out that as per IETF procedures,  

So, i am with you now.

> authors' opinion, as an individual submission with the RFC Editor  

I think this is what we want for draft-behringer.

Thanks

Francois

>
> MSEC or some other WG is free to refer to that RFC to help them  
> decide which option in the solution space is most applicable to  
> their particular use case, of course. But an Informational RFC  
> can't recommend one solution as the TSVWG-preferred approach,  
> especially if that approach isn't an Internet standard.
>
> Lars