Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Thu, 1 Oct 2015 09:31:10 +0100

Hiya,

On 01/10/15 04:52, Suresh Krishnan wrote:
> Hi Stephen,
>    Thanks for your comments. Please find responses inline
> 
> On 09/30/2015 08:06 PM, Stephen Farrell wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-conex-destopt-09: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - section 7: "If the transport network cannot be trusted, IPsec
>> Authentication should be used to ensure integrity of the ConEx
>> information." Hmm. Transport networks cannot be trusted so the
>> first condition is always met. That means you are saying IPsec
>> should be used. I don't see how the key management required is
>> going to happen and even if it did, would that affect conex
>> calculations? I'm ok with an experiment on that basis though,
>> but it'd be better if the real relationship between this and IPsec
>> were more fully fleshed out somewhere as part of the experiment.
> 
> I am not sure if the form of key management chosen would affect the 
> conex calculations at all. 

My point is that the key management implied here is basically not
going to happen. That means IPsec will not be used and hence conex
calculations will need to take into account the potential for routers
to mess with the CDO.

And I think the text of this would be better if it recognised the
improbability of IPsec being used in the wild, or else spoke to how
one could arrange experiments so that use of IPsec is more likely.

Cheers,
S.

> I did read RFC5406 and I am still not sure 
> what can be said here about key management. I would really appreciate 
> some pointers/suggestions/text here.
> 
>>
>> - The secdir review [1] touches on similar issues. I'm not sure if
>> that got a response, but it raises a good point that seems to me to
>> deserve a response.
>>
>>     [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html
> 
> I have added the following text in the Security Considerations section 
> of my local copy. Will submit this version after the telechat will check 
> with Robert. There is one item pending regarding audit in the Gen-ART 
> review and that may end up affecting this text.
> 
>     This document does not define how audit mechanisms work in protocols
>     that use this option and how those protocols can protect themselves
>     from likely attacks.  This option MUST only be used alongside
>     protocols that define the audit mechanisms and the means for
>     protecting against likely attacks on such mechanisms.
> 
> Thanks
> Suresh
> 
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 1 Oct 2015 23:06:32 +0100

Stephen, Suresh,

As the person that contributed some of the text for this IPsec section, 
I can see what's happened during the evolution of the doc...

In section 4 it says

CDO MUST be placed as the first option in the destination option
header before the AH and/or ESP (if present).  IPsec Authentication
Header (AH) MAY be used to verify that the CDO has not been modified.

We started out writing Section 7 "Compatibility with use of IPsec" to 
answering the question:
"What if IPsec is being used; how do we ensure ConEx is still visible?"
The answer was the above rule about placing CDO before AH and/or ESP.

In the process, we showed how endpoints that were already authenticating 
their IP headers with IPsec would automatically get coverage for the 
ConEx header. By some perverse document evolution process, this has become:

[Old]

If the transport network cannot be trusted, IPsec Authentication
should be used to ensure integrity of the ConEx information.

So I suggest the following change:

[Proposed]

If the endpoints are using the IPsec Authentication Header (AH) [RFC4302] to detect alteration of
IP headers along the path, AH will also ensure the e2e integrity of the CDO header.

Actually, both parts of the subsequent sentence are wrong as well:

[Old]

If an attacker would be able to remove the ConEx marks, this could cause an
audit device to penalize the respective connection, while the sender
cannot easily detect that ConEx information is missing.

a) Removing ConEx marks would make audit ignore those packets, not drop 
them.
b) And It's not hard to design a protocol for the sender to detect 
tampering with ConEx information.

So I suggest instead:

[Proposed]
A network-based attacker could alter ConEx information to fool an audit 
function in a downstream network into discarding packets. An attack on 
one network from another by changing an immutable field can be traced, 
so it would be unlikely givennetwork operators care about their 
reputation.Nonetheless, if ConEx information was being altered within a 
network, IPsec AH or other more stealthy e2e integrity checks could be 
useful tools to help pin-point the attack location.

No need to say this, but a similar attack is already possible: decrement 
TTL in one network to cause another network to drop packets. This is 
less easy to trace too, because it uses a mutable field.

BTW, I designed the precursor to ConEx (re-ECN) to make it possible for 
networks to identify other rogue networks mounting such attacks, without 
needing e2e authentication. But all the inter-network security only 
works with ECN, not drop. When we decided to use ConEx to expose drop as 
well as ECN, I couldn't make the drop-based aspects support these nice 
security properties. That is admitted in conex-abstract-mech. But the 
ECN side of ConEx still supports all the inter-domain security. None of 
the inter-domain security techniques are written in the ConEx drafts, 
but they're in my PhD thesis, and referenced from conex-abstract-mech 
Security Considerations.

Bob

On 01/10/15 09:31, Stephen Farrell wrote:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 2 Oct 2015 04:08:47 +0000

Hi Bob,
   Thanks for your clarification. Since the security section seems to 
potentially have some dependence on the text needed for audit to address 
Robert's Gen-ART review, is it possible for you and Mirja to work 
offline and agree to some text before presenting it to the IESG?

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 2 Oct 2015 04:14:26 +0000

Hi Stephen,

> one could arrange experiments so that use of IPsec is more likely.

Thanks. I think it may unfortunately end up being the former. Once the 
audit text is finalized, I will come back with alternate text for this. 
I will keep track of this issue along with Kathleen's DISCUSS as they 
will probably end up needing the same resolution.

Regards
Suresh

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 2 Oct 2015 09:21:09 +0100

Suresh,

Sure - if Mirja is OK with that too.

Bob

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Oct 2015 09:52:50 +0100

Hi Bob,

Those all sound like pretty good changes except perhaps for...

On 01/10/15 23:06, Bob Briscoe wrote:
> reputation.

If the attack is carried out by a compromised node then the goals
of the rightful owner of that node aren't relevant.

> Nonetheless, if ConEx information was being altered within a

I'd omit "more stealthy" unless you want to add a reference. (I
guess that'd be to your Phd thesis and why not include that.)

Cheers,
S.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 6 Oct 2015 00:43:10 +0100

Stephen

On 02/10/15 09:52, Stephen Farrell wrote:
>> so it would be unlikely given network operators care about their
>> reputation.
Yes, I know. I was trying not to side-track too much into a whole 
treatise on all the more damaging and less traceable attacks that become 
possible if a network node is compromised (e.g. the TTL expiry attack I 
mentioned in the email, but not in proposed draft text).

Perhaps the solution is to say less rather than more, and not mention 
operator reputation, given other attacks are more fruitful whether the 
attacker is the operator or not. How about this:

[Proposal #2]
A network-based attacker could alter ConEx information to fool an audit
function in a downstream network into discarding packets. However,
otherexisting attacks from one network on another such a TTL expiry
attacks are more damaging (because ConEx audit discards silently) and
less traceable (because TTL is meant to change, whereas CDO is not).

Then the following para can still pick up on the traceability aspect.
> guess that'd be to your Phd thesis and why not include that.)
I'll leave the authors to decide - a ref to my S.12.1.4 of my thesis at 
this point would work.

Cheers

Bob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 6 Oct 2015 02:02:48 +0100

Hiya,

> less traceable (because TTL is meant to change, whereas CDO is not).

That's better, yes.

Probably no need to address it in this document but I guess our
assumptions about other existing attacks might change as more and
more network traffic is ciphertext at various layers. I'm also
generally leery of arguments of the form "no need to do something
here as there's a worse thing there" since those encourage us to
do nothing anywhere, so I'd lose that kind of language if it can
be done.

S.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 8 Oct 2015 18:02:44 +0200

Hi,

I'm fine with the text below. But a quick question: Is there really a case 
where the attacker would alter the packet to make another network potentially 
drop the packet, instead of juts dropping it on its own?

Mirja

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Oct 2015 12:04:21 +0100

On 08/10/15 17:02, Mirja Kühlewind wrote:
> Hi,
> 
> I'm fine with the text below. But a quick question: Is there really a
> case where the attacker would alter the packet to make another network
> potentially drop the packet, instead of juts dropping it on its own?

Good point. But I guess that'd provide a way for an attacker to hide
their tracks, though so yeah it probably could happen.

S.