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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 30 Sep 2015 17:06:55 -0700

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.

- 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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 1 Oct 2015 03:52:26 +0000

Hi Stephen,
   Thanks for your comments. Please find responses inline

> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/

I am not sure if the form of key management chosen would affect the 
conex calculations at all. 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.

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