TTL/Auth Redux

[Dave Katz <[e-mail]>]

For those not present in Minneapolis yesterday, there was a discussion 
about the issue of what to say about the use of the TTL Hack when 
authentication is in use.  There seemed to be a feeling in the room 
that the use of the TTL Hack in this case was desirable enough so that 
it should be a SHOULD.

I felt (though I was not present, but only participating via audio 
feed) that this was in part driven by Pekka reiterating his concerns 
about a system being somehow involuntarily forced to run repeated 
cryptographic operations, providing a DoS opportunity.  There was also 
some discussion about the order of these two operations.

Toward the end of the discussion, it appeared that Pekka's concerns 
were based on the assumption that a system had to attempt to validate 
any packet carrying authentication that it saw.


I thought it would be worth revisiting the issue one last time, now 
that I think I understand the concern.


In the last rev, I put in the following verbiage:

    If BFD authentication is in use, any value of TTL/Hop Count MAY be
    used in transmitted packets, and received packets MUST NOT be
    discarded based on the received TTL/Hop Count.

My intent was twofold.  First, the only purpose of the TTL check was as 
a really lousy form of authentication--if other forms of authentication 
are in use, the TTL check is unnecessary.  Second, I am concerned about 
the unintended consequences of this check.  There is an existence proof 
(or at least a historical existence proof) of media that appear as a 
single network layer hop, but decrement TTL in mid-link (tunneling 
schemes), as well as systems that decrement TTL when they ought not to. 
  By mandating the TTL hack, BFD could not function across such links, 
but they could be worked around through the use of authentication.  
This ought not to happen, but it has, and if the TTL hack is 
unnecessary, it ought not to be there.  (Not to mention that it is 
truly heinous.)  At least that's my take on the matter.

It's also my contention that if you *are* going to use authentication, 
you *must* have a generic mechanism for avoiding DoS attacks on the 
crypto engine, since otherwise you *must* trust all potential sources 
of packets (in which case the authentication is unnecessary.)


Pekka can correct me if I'm wrong, but I believe he was concerned that 
if a system was running without authentication (and thus making the TTL 
check) and a bad guy off in the distance lobbed in a packet with 
authentication, the system would be obligated to do cryptographic 
processing on the packet.

However, this scenario cannot happen due to the way the base spec is 
written.  First of all, the packet is demuxed by Your Descr.  If it 
doesn't select a session, the packet is discarded.  Next, if packet 
demuxes to a session and the session is not using authentication, the 
packet will be discarded if it has the A bit set.  So at this point, in 
the scenario in question, the packet would have been discarded one way 
or another without ever touching the authentication data.

So the short version is that there is *no* risk of doing *any* 
cryptographic calculation if authentication is not in use.

(One side issue is that "authentication in use" is not a well specified 
term.  I will improve that;  what it means is that authenticated 
packets are being sent and received for a particular session.)


The language, as written, bars the use of TTL hack when authentication 
is in use.  The question is, what should the spec say if someone 
*really* wants to use authentication *and* the TTL hack at the same 
time?

The antiauthoritarian product builder in me notes that any 
implementation is free to deviate from any specification at any time, 
so long as the implications on interoperability are known and it is 
done between consenting adults.  This is arguably hard-headed.

My druthers would be to leave the wording as-is with the belief that it 
is unnecessary and ugly to spec, and implementors can play games as 
they see fit.

However, I can see some wiggle room in this that serves everyones' 
purposes and doesn't introduce any interoperability issues.  That would 
be to say that the sender MUST use TTL 255 (which isn't any burden 
unless you're trying to do some kind of path length limitation, which 
would be even weirder), and that the receiver MAY make the TTL check, 
and have a couple of sentences about the implications of all this.  The 
issue then falls completely on the receiving system, and people can 
lobby their vendors for a knob, and nobody can be accused of being out 
of spec.

Comments?

--Dave