Subject: TTL/Auth Redux

From: Dave Katz <[email-masked]>
Date: Fri, 11 Mar 2005 18:53:48 -0700

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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 13 Mar 2005 20:59:56 +0200 (EET)

On Fri, 11 Mar 2005, Dave Katz wrote:
> 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 have three main concerns:

1) if the system is not configured to use authentication, but the 
attacker sends you packets with Auth bit set which would be 
demultiplexed to an existing or new session -- and you don't discard 
the packets (because the authentication is disabled) before 
demultiplexing occurs, you end up having to perform SHA1 operations on 
the attack packet.  This is an easy demultiplexing computation DoS 
attack.

2) if the system is configured to use authentication, but A bit is not 
set and would be demuxed to an exising or new session, is the packet 
discarded before performing SHA1 computation?  (It seems so, but I'm 
not 100% sure).

3) If the system is configured to use authentication, and A bit is set 
in packets sent from an off-link attacker, the attacker is able to 
perform a SHA1 authentication attack on any router using BFD 
authentication can be mitigated to the local link if TTL=255 check is 
done first.  The result could be that the operators would be _afraid_ 
to turn on authentication because that would open an off-link attack 
vector.

...

For 1) and 2), the spec doesn't appear to be 100% clear what the 
behaviour is (the last sentences of the first paragraph -- maybe this 
is due to the auth/no-auth transition without session reset?) and 3) 
is clearly an issue unless the receivers are mandated to perform 
TTL=255 check unless otherwise configured.

[Section 6.7.6:]
       If the Your Discriminator field is zero, the session MUST be
       selected based on some combination of other fields, possibly
       including source addressing information, the My Discriminator
       field, and the interface over which the packet was received.  The
       exact method of selection is application-specific and is thus
       outside the scope of this specification.  If a matching session is
       not found, a new session may be created, or the packet may be
       discarded.  This choice is outside the scope of this
       specification.

       If the A bit is set and no authentication is in use (bfd.AuthType
       is zero), the packet MUST be discarded.

       If the A bit is clear and authentication is in use (bfd.AuthType
       is nonzero), the packet MUST be discarded.

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

These don't appear to be "single-hop" BFD sessions ?  This seems 
hacking around broken media to be "pseudo single-hop" while they 
really aren't?  While I can see why addressing these may be lucrative 
from the practical point-of-view, maybe we should be just making sure 
that multihop BFD works well in these scenarios?

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

DoS attacks from the same link vs DoS attacks from anywhere in the 
Internet have a very different attack vector.  The operators may 
consider the first case to be acceptable (e.g., the customer's link, 
or semi-trusted IX fabric), but the latter requires another mechanisms 
for security.

Hopefully this clarifies what kind of attacks I'm worried about.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Katz <[email-masked]>
Date: Sun, 13 Mar 2005 13:15:59 -0700

> the attack packet.  This is an easy demultiplexing computation DoS 

I don't understand what you're trying to say.  If the system is not 
configured to use authentication, the system will *never* try to 
authenticate, since it has no means to do so (what would it use for a 
key?)  They will *always* be discarded.  The discard is two-way--if 
authentication is disabled on a session, all authenticated packets will 
be discarded (as well as the opposite.)

So there is no attack possible.

> discarded before performing SHA1 computation?  (It seems so, but I'm 

How could you perform the SHA1 computation on an unauthenticated 
packet?  There's no authentication section, key ID, or hash to verify.  
There is no authentication calculation on unauthenticated packets, 
period, there can't be.  Any implementor who runs a SHA1 checksum over 
the packet before checking whether it's necessary deserves to fail.

> to turn on authentication because that would open an off-link attack 

I'll throw out my argument about the futility of cryptographic 
authentication in an environment that is easily DoS'ed.  But in any 
case, the language I suggested allows the TTL check for people who want 
to do that, it just doesn't mandate it (or bar it.)  The order of the 
checks is outside the scope, as the intent of the protocol spec is not 
to protect half-baked implementations.  Those folks who have DoS-able 
crypto engines are hopefully smart enough to use the tools the right 
way.  The spec is *not* an implementation guide.

>       is nonzero), the packet MUST be discarded.

I don't get what you're trying to say here.  The first paragraph deals 
with the case when you receive the first packet for a session (no Your 
Discr.)  Whether or not you create a session or discard it depends on 
how BFD is being used, and is outside the scope of the base spec.  
Generally you would discard such packets (for example, in the OSPF 
case, both sides know there's going to be a BFD session by virtue of 
the OSPF neighbor relationship) but there are certainly cases where you 
might want to bootstrap a session based purely on BFD.  But this is 
entirely orthogonal to the authentication question.

As I said before, if a system is capable of being swamped by 
authentication, then it is free to turn on the TTL check as the 
verbiage at the end of my last missive suggested.

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

The fact is that they have existed, they may exist in the future, and 
that their presence may not be known unless somebody is watching TTLs 
carefully.  But it doesn't matter, based on my suggested change.

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

So now I'm completely lost.  Is my suggested verbiage acceptable or 
not?  The rest of this becomes purely academic if it is.  Frankly, I'm 
finding this whole exchange rather frustrating.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Mar 2005 16:05:08 +0200 (EET)

Hi,

(I agree that 1) and 2) don't seem to be real problems except with 
really, really broken implementations, so let's not focus on them. 
Sorry about confusion.)  More inline..

On Sun, 13 Mar 2005, Dave Katz wrote:
>> 3) If the system is configured to use authentication, and A bit is set in 
>> packets sent from an off-link attacker, the attacker is able to perform a 
>> SHA1 authentication attack on any router using BFD authentication can be 
>> mitigated to the local link if TTL=255 check is done first.  The result 
>> could be that the operators would be _afraid_ to turn on authentication 
>> because that would open an off-link attack vector.
>
> I'll throw out my argument about the futility of cryptographic authentication 
> in an environment that is easily DoS'ed.  But in any case, the language I 
> suggested allows the TTL check for people who want to do that, it just 
> doesn't mandate it (or bar it.)  The order of the checks is outside the 
> scope, as the intent of the protocol spec is not to protect half-baked 
> implementations.  Those folks who have DoS-able crypto engines are hopefully 
> smart enough to use the tools the right way.  The spec is *not* an 
> implementation guide.

I don't disagree from what's the bare minimum for the protocol spec, 
but nowadays the specs also must have a security considerations 
section ;-).  The security behaviour in the protocol is very 
unpredictable unless there is also specification about the security 
properties of the system.  And that's exactly what those couple of 
uppercase statements on TTL checking try to do.

>> These don't appear to be "single-hop" BFD sessions ?  This seems hacking 
>> around broken media to be "pseudo single-hop" while they really aren't? 
>> While I can see why addressing these may be lucrative from the practical 
>> point-of-view, maybe we should be just making sure that multihop BFD works 
>> well in these scenarios?
>
> The fact is that they have existed, they may exist in the future, and that 
> their presence may not be known unless somebody is watching TTLs carefully. 
> But it doesn't matter, based on my suggested change.

But do these happen, just out of the blue without the session being 
reset?  If the BFD session does not form when it's initially 
configured, for the first time, the network admin may suspect that 
this is the case, and disable TTL checking.

> So now I'm completely lost.  Is my suggested verbiage acceptable or not?  The 
> rest of this becomes purely academic if it is.  Frankly, I'm finding this 
> whole exchange rather frustrating.

I was just trying to get an understanding on the attacks first.
You suggested:

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

This is a good direction, but I we should have use "SHOULD [...] 
unless configured otherwise" rather than MAY. (I think this was pretty 
close to what the WG seemed to feel in MPLS.)  In addition, it 
wouldn't hurt to have some text also recommending to have a 
configuration knob for this feature, but I'm OK with leaving that out 
because you'd argue the spec is not an implementation guide ;-).

---

From: Dave Katz <[email-masked]>
Date: Mon, 14 Mar 2005 14:09:51 -0700

On Mar 14, 2005, at 7:05 AM, Pekka Savola wrote:

>> case, the language I suggested allows the TTL check for people who 
>> want to do that, it just doesn't mandate it (or bar it.)  The order 
>> of the checks is outside the scope, as the intent of the protocol 
>> spec is not to protect half-baked implementations.  Those folks who 
>> have DoS-able crypto engines are hopefully smart enough to use the 
>> tools the right way.  The spec is *not* an implementation guide.
>

There is a Security Considerations section, as you know.  Actually, 
that section in the base spec currently mandates the TTL hack, 
something that dates to before authentication was added.  I'll fix that 
language (it probably shouldn't be in the base spec, but should 
reference the 1hop spec instead.)  I can add a couple of sentences 
about the DoS exposure there.

The security behavior of the protocol is entirely predictable.  It's 
the security behavior of the *implementation* that is unpredictable, 
and as such is outside the scope of the protocol spec.

It sounds as though someone should write an informational RFC or BCP on 
this stuff (I have neither the time nor the inclination).

> because you'd argue the spec is not an implementation guide ;-).

Please go back and read the definition of SHOULD and MAY.  SHOULD says, 
in so many words, that you better have a really good reason, and really 
know what you're doing, to go against the clause.  MAY says that it's 
fully optional, but you need to be able to interoperate either way.

"SHOULD unless configured otherwise" isn't valid specsmanship.

As the only reason that one would be forced to do the TTL check is if 
the crypto engine is substandard, that to me does not fall into the 
SHOULD category, which ought to apply only to those situations whereby 
the bulk of implementations are skating on thin ice if they go against 
it.

This check ought to be purely optional, as (a) any useful crypto 
implementation will not have this issue, and (b) there is no 
interoperability issue regardless of which way you go (with the revised 
text), and (c) the TTL check is nothing to be proud of and should be 
avoided if possible (IMHO.)  If you referred to the TTL check as 
"security" to one of the security guys, I think they might beg to 
differ.

I will happily put in some text to explain the issue, as I said earlier.

 From a practical standpoint, the outcome is the same--you will ask for 
the feature from your vendor and they will probably deliver it.

My feeling as far as the meeting goes was that there was not sufficient 
discussion for those in the room to make an informed decision (made 
worse by my participating through a five second delay), and if I 
understand the Rules of Engagement correctly, the meetings are advisory 
and the mailing list is the determining factor.

Therefore, in order to try to put this issue to bed, I offer the 
following text for the indicated two sections in the 1hop draft.  
Unless there is significant and informed opposition to the text, I will 
publish it as written and we can move on.

--Dave

5. TTL/Hop Count Issues

    If BFD authentication is not in use on a session, all BFD Control
    packets for the session MUST be sent with a TTL or Hop Count value of
    255.  All received BFD Control packets that are demultiplexed to the
    session MUST be discarded if the received TTL or Hop Count is not
    equal to 255.  A discussion of this mechanism can be found in [GTSM].

    If BFD authentication is in use on a session, all BFD Control packets
    MUST be sent with a TTL or Hop Count value of 255.  All received BFD
    Control packets that are demultiplexed the session MAY be discarded
    if the received TTL or Hop Count is not equal to 255.

    In the context of this section, "authentication in use" means that
    the system is sending BFD control packets with the Authentication bit
    set and with the Authentication Section included, and that all
    unauthenticated packets demultiplexed to the session are discarded,
    per the BFD base specification.

Security Considerations

    In this application, the use of TTL=255 on transmit and receive is
    viewed as supplying equivalent security characteristics to other
    protocols used in the infrastructure, as it is not trivially
    spoofable.  The security implications of this mechanism are further
    discussed in the GTSM specification.

    The security implications of the use of BFD Authentication are
    discussed in the base BFD specification.

    The use of the TTL=255 check simultaneously with BFD Authentication
    provides a low overhead mechanism for discarding a class of
    unauthorized packets and may be useful in implementations in which
    cryptographic checksum use is susceptable to denial of service
    attacks.  The use or non-use of this mechanism does not impact
    interoperability.

---

From: David Ward <[email-masked]>
Date: Mon, 14 Mar 2005 17:58:39 -0600

Dave -

Good news and bad news in this email message, read below.

At 2:09 PM -0700 3/14/05, Dave Katz wrote:
>>>authentication in an environment that is easily DoS'ed.  But in 
>>>any case, the language I suggested allows the TTL check for people 
>>>who want to do that, it just doesn't mandate it (or bar it.)  The 
>>>order of the checks is outside the scope, as the intent of the 
>>>protocol spec is not to protect half-baked implementations.  Those 
>>>folks who have DoS-able crypto engines are hopefully smart enough 
>>>to use the tools the right way.  The spec is *not* an 
>>>implementation guide.
>>
>>I don't disagree from what's the bare minimum for the protocol 
>>spec, but nowadays the specs also must have a security 
>>considerations section ;-).  The security behaviour in the protocol 
>>is very unpredictable unless there is also specification about the 
>>security properties of the system.  And that's exactly what those 
>>couple of uppercase statements on TTL checking try to do.
>
>something that dates to before authentication was added.  I'll fix 
>that language (it probably shouldn't be in the base spec, but should 
>It sounds as though someone should write an informational RFC or BCP 
>on this stuff (I have neither the time nor the inclination).

What you ask for is well documented in RFC 3682. What is being asked 
of you is to restate/rewrite the GTSH problem/purpose statement here. 
It isn't necessary thanks to the ability to reference it.

>>>limitation, which would be even weirder), and that the receiver 
>>>MAY make the TTL check, and have a couple of sentences about the 
>>>receiving system, and people can lobby their vendors for a knob, 
>>>and nobody can be accused of being out of spec.
>>
>>unless configured otherwise" rather than MAY. (I think this was 
>>pretty close to what the WG seemed to feel in MPLS.)  In addition, 
>>it wouldn't hurt to have some text also recommending to have a 
>>configuration knob for this feature, but I'm OK with leaving that 
>>out because you'd argue the spec is not an implementation guide ;-).
>
>Please go back and read the definition of SHOULD and MAY.  SHOULD 
>says, in so many words, that you better have a really good reason, 
>and really know what you're doing, to go against the clause.  MAY 
>says that it's fully optional, but you need to be able to 
>interoperate either way.
>
>As the only reason that one would be forced to do the TTL check is 
>if the crypto engine is substandard, that to me does not fall into 
>the SHOULD category, which ought to apply only to those situations 
>whereby the bulk of implementations are skating on thin ice if they 
>go against it.
>
>interoperability issue regardless of which way you go (with the 
>revised text), and (c) the TTL check is nothing to be proud of and 
>should be avoided if possible (IMHO.)  If you referred to the TTL 
>check as "security" to one of the security guys, I think they might 
>beg to differ.

What you have written here Dave is what is stated in RFC 3682

quoting:

"3.  GTSM Procedure

    GTSM SHOULD NOT be enabled by default. "

So, it seems that the desire to change this RFC is being pushed 
through the BFD singlehop.

>From a practical standpoint, the outcome is the same--you will ask 
>for the feature from your vendor and they will probably deliver it.
>
>
>My feeling as far as the meeting goes was that there was not 
>sufficient discussion for those in the room to make an informed 
>decision (made worse by my participating through a five second 
>delay), and if I understand the Rules of Engagement correctly, the 
>meetings are advisory and the mailing list is the determining factor.

The mailing list is the determining factor.

>Unless there is significant and informed opposition to the text, I 
>will publish it as written and we can move on.
>
>--Dave
>
>
>
>5. TTL/Hop Count Issues
>

These paragraphs are completely clear, concise and remove any issues. 
The MUST associated w/ the TTL check is in fact too strong for many 
smaller devices (the assumption in this conversation seems to be 
considering only core devices and not other devices) on a global 
basis. RFC 3682 refers to enabling GTSH on a per peer basis and as 
OPTIONAL.

I cannot understand why we are trying to force BFD to be *specified* 
differently than other protocols. No other protocols have a MUST. 
Also, the specific mention of 255 will preclude any two stage 
forwarding router from decrement TTL on ingress but, BFD TTL check be 
done on another board. IMHO, we are prescribing implementation in the 
sentences above, we can't do that.

In the end, the paragraphs can put the conversation to bed in a much 
more strict and restricting yet no more secure definition.

>    discussed in the GTSM specification.

Use brackets for the normative reference

>    attacks.  The use or non-use of this mechanism does not impact

This is fine and correct.

-DWard

---

From: Dave Katz <[email-masked]>
Date: Mon, 14 Mar 2005 17:14:39 -0700

> Use brackets for the normative reference

Do these need to be in every reference, or just the first?  It is 
bracketed in section 5.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Mar 2005 19:52:13 +0200 (EET)

Responding to both Daves..

On Mon, 14 Mar 2005, David Ward wrote:
> So, it seems that the desire to change this RFC is being pushed through the 
> BFD singlehop.

I think the key thing to remember is why GSTM spec says that. 
AFAICS, they don't want to break backward compatibility with the 
existing base of BGP, MSDP, and whatnot protocols which didn't support 
GTSM from day one.

However, BFD did, so this should not be a technical factor.

> "SHOULD unless configured otherwise" isn't valid specsmanship.

The text was an oversimplification.  It could be said, for example,

                                                   All received BFD
    Control packets that are demultiplexed SHOULD be discarded
    if the received TTL or Hop Count is not equal to 255.
    If such packets are not discarded by default, the implementation
    MUST have a configuration toggle to enable the discarding.

or:

                                                   All received BFD
    Control packets that are demultiplexed SHOULD be discarded
    if the received TTL or Hop Count is not equal to 255.  If the
    implementation chooses not to do this by default, it MUST have a
    configuration toggle to enable the discarding.

(note, there appeared to be extra "the session" around 
'demultiplexed')

I could even live with the above wording if the first "SHOULD be 
discarded" was a MAY, i.e., if the still spec had a MUST for 
implementing the toggle for implementations which don't do it.

Otherwise, the text that dkatz proposed seemed pretty good.

---

From: Dave Katz <[email-masked]>
Date: Tue, 15 Mar 2005 13:15:50 -0700

On Mar 15, 2005, at 10:52 AM, Pekka Savola wrote:

> (note, there appeared to be extra "the session" around 'demultiplexed')
>

The spec *cannot* dictate implementation.  *Every* protocol has issues 
where implementors can be stupid (never underestimate the power of 
cluelessness.)  Why should this be any different?  Implementors must be 
free to implement or not implement the TTL discard behavior according 
to the needs and capabilities of their product.  If I have a good 
crypto engine that does the right thing, why should I have to implement 
this?  Further, as Dave2 points out, it may be entirely impossible to 
implement depending on the system architecture.

I think what you are really trying to have the spec say is, "if your 
crypto implementation is broken, you MUST do the TTL hack."  That 
doesn't belong in a spec either.

The spec calls out the issue, and allows both implementors and 
customers to make informed decisions.  This is more than most protocol 
specs do.

The text I proposed (modulo editorial fixes) lays out the issue very 
plainly, and I believe strikes the right balance between your concerns 
and mine.

Can we *please* move on?

--Dave