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

[RJ Atkinson <[e-mail]>]

On  28 Jan 2008, at 04:59, Francois Le Faucheur wrote:
> On 24 Jan 2008, at 18:04, Lars Eggert wrote:
>
>> (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,
     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 ?

> I am not aware of any solution currently available from the IETF to  
> actually deploy such distribution of group keys for RSVP.

Agreed.

> 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.

That all sounds reasonable to me.

> (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.)

Agreed.

> 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.

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).

> 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).

Agreed on all points.