2.6.1 Better-Than-Nothing Security (btns)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-28


Joseph Touch <touch@isi.edu>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>

Security Area Advisor:

Steven Bellovin <smb@research.att.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Current Internet Protocol security (IPsec) protocols present somewhat of
an all-or-nothing alternative; existing protocols provide protection
from a wide array of possible threats, but are sometimes not deployed
because of the need for cumbersome management key infrastructure,
complex configuration, or because of their performance impact. This
proposed working group will develop extensions to existing Internet
Protocol security (IPsec) protocols to support relaxed variants that
reduce their need for pre-shared keys and/or key management
infrastructure, and/or increase their performance (higher bandwidth,
lower CPU cost, lower latency). These relaxed variants provide weaker
security guarantees than their conventional counterparts, but should be
sufficient for use in limited environments, e.g., to protect against
off-path attacks but not man-in-the-middle, or to protect connections
without regard for authoritative identification of communicating
parties. The goal of these relaxed variants is to enable and encourage
the use of network security where it has been difficult to deploy -
notably, to enable simpler, more rapid deployment and to support
security in high-performance environments. (the WG will focus on IPsec
on its instantiation; after completing work on IPsec, the WG may seek
rechartering to consider other Internet security protocols)

The WG has the following specific goals over three IETF meetings:
    a) characterize a reasonable set of threat models with
      relaxed assumptions suitable for infrastructure-free
      and/or high-performance use
    b) identify existing IPsec standards track protocols for
      extension and determine whether configuration (BCP) or
      extension (standards-track) is appropriate for each
    c) document protocol configurations and/or extensions for
      infrastructure-free use
    d) document protocol configurations and/or extensions for
      high performance use

The current ANONSEC ID will serve as the initial issues (requirements)
document. Items (a) and (b) above comprise the framework document. Each
protocol specification modified as per (c) and/or (d) will comprise a
separate WG contribution. One or more of these contributions will be
published as BCPs (requirements, framework, and configurations not
requiring protocol variation) or standards-track documents (for
protocols requiring variations).

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

BTNS Meeting Draft Minutes (final - 12/7/2004)

IETF 61, Wash. DC
November 9, 2004

CHAIR: Joe Touch (touch@isi.edu)

<<Overview presentation>> (Joe Touch)

<<Discussion about ANONsec Overview>>

Bill Sommerfeld (Bill) - Generally a good idea. Need to pay attention to co-existing with authenticated and non-authenticated IPsec within the same implementation. That has to be a key requirement (not to make things weaker if you have preconfigured IPsec security).

Sam Hartman (Sam or AD) - (As individual) Couple of other problems may be solved by the same solution to this problem. If it doesn't get in the way, it would be good to solve it all. When auth might happen in different layer. This could make things happening in other wgs easier to deal with

Steve Kent (Steve) - Must think about a few things. This relaxes the threat model we have adopted for the past 8 or 9 years. Need to say why we don't think MITM attacks are viable. (That's in some cases naive...)

Joe Touch (Joe) - People are doing IPsec or nothing. This is better than nothing, but not a substitute for full security. It's a gentle way to get your feet wet. Consider Spam. People don't do full SPAM solutions at once. They put in a bit and then a bit more depending on the level of annoyance. Moderate investment incrementally depending on concern and amount of attack.

Steve - Fair observation. But this could be considered a way to avoid doing the better/right thing. The result is temporary thing replaces the real/better thing. (...something about a building in MIT as an example...)

Joe - If this is done when designing IPsec, it would be dangerous. But IPsec is mostly done, and there are cases where it is important to protect persistent connections without having to go to Verisign, and it would be nice to get safe connections without the infrastructure requirements.

Steve - But wouldn't the attack in that case be MITM? Eg., things that are more cookie-based are more attractive. It had been briefly discussed in IPsec wg. In the context of BGP, control traffic is the area of concern. Need a way to distinguish traffic from legit sources. Need something at a low level to rule them out as legit.

Joe - A related issue, it might be attractive to do high speed things at low level and smarter stuff at higher level.

Steve - Saw a number of attacks that have been executed when one disconnects authentication. It isn't comparable security (?). If you put this up as motivation, be prepared to be bitten quite a bit. We've seen issues in IPsec when using encryptions without authentication (?) and tried bringing in EAP ... and nasty things happened ... Need to narrow focus.

Sam - Are you talking about than EAP issues logged?

Steve - I've seen lots of stuff over through years. Don't do things that create problems.

Sam - This is better than nothing, it'd be great if we can solve our problems without it.(?)

Steve - Weakening ipsec is bad. Not sure we would want to go down that path.

AD - Take this offline.

Eric Resocorla (Eric) - Seems to suggest that difficulty to prevent on-path and off-path attacks are not the same. IPsec is not used for two reasons: (1) IKE keying with properly certified symmetric keys is difficult; (2) IPsec ESP/AH for the whole packet is too slow.
You are proposing to (1) relax requirements with IKE and (2) design new encryption (encapsulation?) format with partial coverage. Should these be done at the same forum? Is it worth being a wg to do the first? If we do the first, is the second necessary? Is the second worth spinning a wg to do?
Don't know the state of IKEv2 (Charlie Kaufman: It's in the RFC Editor). For the first, how difficult it is to relax the constraints. There is a threat model where relaxing the requirement for fully qualified authentication.
Original notes:

Joe - The concern is that: Is it necessary to do it? Yes. But why isn't people turning it on? The point is that (1) relaxes the requirement on infrastructure.

Eric - Sounds reasonable. If the first is done, how hard is it to do the second? Or is it necessary?

Joe - When you do (1), (2) is what you also have to do.

Eric - One doesn't necessarily need another.

David Black (Dave) - I chair both IPS and RDDP wgs. Agree with Sam's points on why this is interesting. This is interesting with potentially two level structure. Both wgs use IPsec, and IPsec requires deploying keys in advance which is a hassle. This hassle causes use of things like group pre-shared keys. People look down on it, but use them because it is convenient. This has potential to be better than preshared keys. Better for these groups to use it.
Disagree with the bit about writing off MITM attacks. It is only for initial setup, afterwards there is a fair amount of protection because if the attacker missed the setup, then the connection is protected.
Also an opportunity for protocols with higher-level authentication. It is not a substitute for higher-level auth, but done on initial setup and linked with real authentication and identity.

Joe - Question: if the first step do this, the second is to get the linkage to multiple layer to multiple protocols?

David - Agree. Get this, then produce the information that is needed to do the linkage, and leave the actual linkage to the individual protocols. Part of this setup is needed to support the linkage protocol by protocol. At least we have a standard way to say setup, and here is the pieces of crypto that says what was setup. Similar to IPsec with higher layer authentication. This is better than today ... IPsec under covers ... then other stuff ... pray that the identities match between IPsec and the higher layer authentication.

Nicolas William (Nico) - The name BTNS is a decent compromise, though in the case of unauthenticated key exchange plus channel bindings this is much better than nothing, which 'BTNS' fails to convey, but can live with it.
Re: channel binding, many existing protocols perform a DH key exchange and then authenticate it all at the same layer; with channel bindings we get to move the authentication to higher layers while keeping the binding between the two. As long as the channels at both layers are end-to-end (e.g., we're not using group-shared keys for IPsec) then this adds no new vulnerabilities as compared to the traditional key-exchange-and-authentication-at-the-same-layer approach.

Caitlin Bestler (Caitlin) - Concerns are for high speed networking (10 Gig) that most of the traffic is over a scope where the switching/routing elements are known and carefully enumerated. MITM attacks have been prevented by physical configuration and/or physical design (for example within a blade server rack).
IPsec, as currently defined, will at least initially only be offered for a subset of the available wire speed (if at all). Customers who have bought a 10 gig solution for a safe environment will not want to enable full IPsec if it slows down *all* of their traffic when only 1% of their traffic is at risk of MITM attacks.
An ideal solution would allow full IPsec with protection against MITM attacks when a path leaves the "safe neighborhood" and a lower overhead security (such as the partial 'hash' or cookie-only) for the bulk of the traffic.
Also suggest to investigate an automated method of identifying the "safe neighborhood" might be preferable to relying on the judgment of the local sysadmins. Basically, within data-center/blade environments, if customers are forced into the all-or-nothing choice they will choose nothing.

Joe - out of scope, but keep in mind

Charlie Kauffman (Charlie) - It is a great idea. What will buy us a lot is the observation that the best is the enemy of the good, ... It'd be bad if people think it is good enough and they would never deploy IPsec. IMO, a much better model to make people do IPsec sooner to have this first, then crank it up as needed later. Disagree with Eric, we don't need to come up with all components to solve the problem. The protocols are there, just need to profile things needed. Don't need to split things up (into separate wgs).

Joe - have some slides for configuring of existing systems, ways of saying when not to abort, modified version of existing things, etc. We are not building things from ground up.

Steve - Respond to Dave Black. I commented on the slide that we were not going to consider MITM attack. Dave was right that the point in time that MITM attack would occur. This needs clarification.

Joe - During initial key setup and after keying while you are transmitting. Then we look at the three options.

Steve - Disagree with Charlie. I think they are separate. Blind DH is different from the other mod, partial hashes/encryption. The first is very well constrained and easier to talk about within existing protocols. The second is not IPsec-compliant. In different environments, some might need the second without blind keying. If we link them together, it might preclude using the second one with traditional key management.

Joe - Winking the two together was more a wg admin thing. There will be separate ID's/RFC's.

Steve - Querying infrastructure to see if it is safe ... let's not go there.

AD - Keep comments to scope level.

Joe - Scope discussion later.

Matsushita (???) - We did MITM IPsec. It can be easy to prevent if don't use preshare keys. Please let me know if you are interested.

Michael Richardson (Mike) - Trying to understand the motivation when it comes to putting things together. I think you are trying to solve BGP problem rather than TCP. I think that is where we need to rethink scope. The justification of what you put in here is getting this turned on for a very small subset of people, so the scope is meaningless. Also, the first part is enough for that. The second part is pre-mature.

Joe - People do care about performance impact. People deploy IPsec for VPN's which are for all traffic, also on a leased line whose bandwidth you have purchased.

Mike - BGP is inter-enterprise. VPN's are within enterprises. VPN requires a lot more operational standardizations. (...) If we do this right, there will be a knob as Charlie says, not an ON/OFF switch. This should be in scope.

Richard Graveman (Richard) - Dubious about the hash part, by the time you move the data around, might as well do it off. The keying (faster MAC) is the more interesting part. Also echoing other people that don't break existing security. The knob is critical, let's get a path to the better security. That should be a design constraint.

Joe - What isn't the knob about what I am doing?

Richard - Depends on what we choose. A cookie mechanism in IKE does not lead in the right direction.

Joe - Lead means I can re-key?

Mike - Depends on the sort of cookie you use. You can add auth tomorrow.

Joe - What is the difference between adding to a field that was empty before adding something new?

Richard - I was talking requirements, not solutions.

Josh Hartman - We may need changes to ike to allow negotiating the partial hashes.

Joe - Yes.

Uri Blumenthal - The proposal was relaxing the certification of keys and other things. Don't understand other things and question the necessity. Would love non-preshared and non-authenticated keys, similar to SSH, and have them configurable. I think things should be split cleanly between this and the rest.

AD - Chair asked for comments on the presentation. Most comments are not. Let's proceed.

Joe - Next is scope discussion.

someone(?) from Ericsson - This for TCP attack only. Not good for BGP because could not verify who the peer is that gives you the routes. Lose security.

AD - Not a question for presentation.
Will ask two questions: A general question and (1) the keying changes to support anonymous IKE; (2) second part about partial hashes.

<<Scope presentation slides>>

Gregory Lebovitz (Greg) - Is it possible when we get things worked out for wgs to apply it themselves? A separate wg for IPsec?

Joe - Possible. Case-by-case basis.

<<Charter discussion>>

Bill - 2nd one has both IPsec & IKE in it.

Joe - Yes.

Sam - (as individual) Support previous comments by Dave B, Nico, and others about the idea of making information available to higher levels. This could affect the applicability statement. If we have two solutions, one permits that use and one doesn't, I prefer the first. It would affect wording of the charter. If sufficient support for that, then update the charter. Would like it all done in one place.

Steve - Don't understand this suggestion.

Sam - (Nico's idea) concerned about providing info to higher layers.

Steve - That's not security gateway.

Sam - That's a question for applicability statement. Might decide to use for security gateways or not.

Steve - Concerned about providing info to higher layers, that's end-to-end, not for intermediate systems.

AD - Reasonable to provide functions useful in one case and not the other. Just not mandatory.

Joe - Solution enables it, not requires it.

Eric - Do we need the third doc? Could just say self-signed certs are fine for IKE. Problem solved.

Joe - Could be a short doc. More about config than mods to IKE. But still need to talk about conditions of use, coordinations with other aspects. Other issues to be covered.

Bill - The bits on the wire bit is simple. It's the rest that will make it longer.

Dave - This will impact security policy database. Agree with Bill's point about self-signed certs. Need to control their use and will be a big part of security model. I'd put my time into this to work higher protocol support bit. Security gateway probably want to use existing IPsec/IKE.

Nico - Support two separate docs for propose standards for practical reasons. If only want the un-authenticated key bit, would want a normative reference to just that bit. Also the IKE part will not be that simple. Many implications about what ID to use a reference to SPD, etc.

<<Related Work slides>>

AD - Many don't see why modern (faster) hashes were not good enough. Only heard one person who said the partial hash was critical. Want to see discussion in favor or against that work being done (here).

Mike - This work is at IPsec and protocol layer, not EAP. IKEv2 can easily negotiate such things. This (second part?) can be done as an individual submission. I think someone should implement what they want and write that up. If this wg needs to look at it and decide whether to adopt it. Until we solve the first problem, which BGP is the killer app for. ... Want to see a big router with large number of peering sessions, turn it on, and complained about lower level too slow. I don't think they will say that. If router venders don't want it no one will.

Joe - Ask why Cisco don't have IPsec for v6. It's too slow. OK in hardware, but too slow otherwise.

Mike - IPv6 is mostly software, not ASIC, therefore slow. It's the policy extension that's slow, not the packets. That doesn't matter for BGP because they do it with control plane, not forwarding plane.
I think the lower level work is premature optimization, goes down a road where others have tried to drag IPsec wg many times. We keep saying we don't want to go there.
The other stuff is the most important to cure world hunger and put it together with what will cause world hunger.

Caitlin - Two problems with same symptom: all or nothing security. But the all-or-nothing portion is the problem. Without hash reduction/optimization, it will not get anything turned on. Full hash will prevent people from using it at high speed.

Eric - Mike said something important. Let's measure it before making performance optimization.

Joe - Should take this offline. Performance issue is a red herring. The primary issue is cookie vs. full or partial.

Eric - Need to carefully enumerate the threat models. Not completely sold to that environment (...?) that no reasonable hardware to do the job with.

Pekka Savola (Savola) - Speaking as network operator. I think it's bogus to list BGP peering as one important bit that needs this. Would not base this work on BGP scenario, but on others. If network is properly managed, BGP can survive without this but with a lot of other stuff.

Joe - That is my point. We can either modify it with every protocol or we can fix it properly in the security layer. <examples of bad hacks, TTL=255 not a good indicator because can't assume routers only decrement TTL by 1 ...> It is more appropriate to use anti-spoofing mechanism.

Savola - One inaccurate thing: router decrements TTL by 1 not quite right. The right question is what do operators want to deploy. I am an operator and I don't want to deploy this for BGP. We want hacks. They are operationally simpler than this approach.

Joe - For BGP, there are two ways to solve it: (1) load IOS with unknown patch/hack to a core Internet protocol; or (2) use RFC standard method. Half the people were more comfortable with the hack.

Savola - If you don't want to protect agains spoofing, and hope there are operators that want to prevent(?) spoofing in the core and edges, then this isn't necessary.

Richard - We have not explored all possible faster, better MACs. Things could get faster there instead of hashing. Maybe should drop hashing.

Nico - Curious about what storage industry thinks. Is performance really such a big deal so they turn off IPsec? BGP is different from storage, the keying part is the killer. Not sure the performance part is necessary.

Joe - Can look at this, But there are more cases here than just BGP and data centers. Sometimes you either don't want to effect performance or not overload the routers. This work is only motivated by BGP problem, but is not aimed at BGP only.

Bob Moskowitz (Bob) - Re: performance question, 802.1ae must support 10 gigabit, and there is work on new high speed dual mode cipher which may give performance some people are asking for. For data centers, may have IPsec right now, 802.1ae could be better.
IPsec does not call out a key management methodology, only manual keying is mandatory. If only want to day just use keys and go away, that's in current protocols.

Dave - Comment on storage community interests. My view is keying modification to use self-signed keys is much more interesting than the hash work. The work Bob mentioned is more promising (in terms of performance).

Joe - Grid also does storage, not in the LAN as data center.

Dave - Fixing keying is more important. Reducing integrity coverage to increase security performance is of significantly less interest.

AD - Seem to repeat ourselves. Anything new?

Bob - Walmart is allowing self-signed certs exchange by purchasing agents, a major commitment from the largest retailer in the States.

AD - Two questions, depending on the answers, may work or charter or go home:
Q1: who wants to see the keying work to go forward?
For: loud hum
Against: none (quiet)
Q2: performance/hashing question?
For: some hum
Against: much louder
Rough consensus for first, against second.
Move on to the charter. Need wordsmithing, then we nail it down on the mailing list after IESG?

Joe - Charter needs to change as a result of this discussion.

Pekka Nikander (Nikander) - Do we have consensus on providing information for the upper layer? If that goes in the charter, does it mean API? What is the idea?

AD - Might have implications on applicability statement. Want to have something to bind to when you setup the keys that are stable; could be session IDs or automatic if you have self-signed certs.

Nikander - Specific question: for that to be useful, need doc to define what and how the info is available, BCP or informational.

AD - Yes, but not sure in this wg. Others are already working on these. Kitten wg has a more generic doc in that space, so does rddp.
Another question: are people interested in looking into the issue in channel binding when designing the applicability statement and the implications on IKE?
For: hums
Against: none

Bill - Make sure we don't preclude work from other groups.

Greg - Related: Easy cert BoF (later) also try to make certs easier to use. Would this overlap?

AD - Easy cert is not targeting to create a working group.

Nico - APIs for channel binding, one of the policy wgs has a bit of that.

Dave - Don't care about API, care about detailed specification on what is created and that I need to bind to, how to bind to an IPsec once it's created. Then people should pick it up and use it. That doc is needed. I'll leave it to the AD as to where the work is done.

AD - Agree, perhaps not here. (someone mentioned IPsec wg)

Joe - IPsec wg is mostly done.

Dave - What to bind to IPsec should from security groups, Out of scope for this.

Joe - Edited problem statement, delete the performance part.

<<reading charter>>

Steve - Texts keeps talking about IPsec, but this is only IKE.

Joe - I first used security protocols, but was told by AD to use IPsec. Maybe should use IKE.

Bill - Playing nice with IPsec. Part of it isn't just IKE, but also SPD.

Joe - Is it just wording or something more fundamental?

Steve - It could be pad issue, not SPD. If want to use IPsec but just need self-sign certs, that can be done now, no wg action required. Pad definition allows it,

Joe - (???) The goal of rephrasing is to describe areas to be fixed, don't want the charter to give solutions.

Steve - Do this on mailing list.

AD - The goals are to describe what work we are doing and particular we don't want the group to wander.

Steve - The problem is not accurately describe because of the wording.

AD - Take it to the mailing list.

Joe - Blue sheets & we are done.


Overview of BTNS goals and ANONsec I-D