Re: [conex] Kathleen Moriarty's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)

[Bob Briscoe <[e-mail]>]

Kathleen, Suresh,

I've tried to reload state to get this sorted (I had to check back over 
the last 4 sets of diffs)...

Kathleen's right - the encryption text shouldn't have been removed. I 
thought we merely agreed it needed to clarify that it was talking about 
where to put the CDO to ensure it is not encrypted, if IPsec is being 
used to encrypt other data.

Reading the IPSec section afresh, I could not make sense of it. The 
logical flow is missing - it's not clear which parts of each para are 
explaining a problem, and which parts are solving the problem.

Here's my attempts to fix this:

OLD:

    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.  A network-based
    attacker could alter ConEx information to fool an audit function in a
    downstream network into discarding packets.  However, other existing
    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).

NEW;

    A network-based
    attacker could alter ConEx information to fool an audit function in a
    downstream network into discarding packets.
    If the endpoints are using the IPsec Authentication Header (AH)
    [RFC4302] to detect alteration of IP headers along the path, AH will
    also detect alteration of the CDO header. Nonetheless, AH protection
    will rarely need to be introduced for ConEx, because attacks by one
    network on another are rare if they are traceable. Other known
    attacks from one network on another such a TTL expiry attacks are
    more damaging to the innocent network (because ConEx audit discards 
silently) and less
    traceable (because TTL is meant to change, whereas CDO is not).

REASONING:
Stated the current position and the problem before the solution.
AH does not ensure integrity, it only detects lack of integrity.
Added sentence to explain why we're only talking about existing use of 
AH, not adding it, which also better justifies the last sentence, which 
Stephen Farrell didn't really like, but grudgingly accepted.
s/existing/known/ to avoid implying networks are routinely attacking 
other networks with TTL expiry attacks.
Added "to the innocent network", to make it clear that the damage being 
discussed is the shift of blame to another network, not the resultant 
lack of e2e delivery.

OLD:

    Inside an IPv6 packet, a Destination Option header can be placed in
    two possible positions, either before the Routing header or after the
    ESP/AH headers as described in Section 4.1 of [RFC2460].  When the
    CDO is placed in the destination option header before the AH and/or
    ESP, it is not encrypted in transport mode [RFC4301].  Otherwise, if
    the CDO were placed in the latter position and an ESP header was used
    with encryption, the CDO cannot be viewed and interpreted by ConEx-
    aware intermediate nodes effectively rendering it useless.


NEW;

    Section 4 specifies that CDO is placed in the destination option header
    before the AH and/or ESP headers so that ConEx information remains
    in the clear if ESP is being used to encrypt other transmitted 
information
    in transport mode [RFC4301].
    Inside an IPv6 packet, a Destination Option header can be placed in
    two possible positions, either before the Routing header or after the
    ESP/AH headers as described in Section 4.1 of [RFC2460]. If
    the CDO were placed in the latter position and an ESP header was used
    with encryption, ConEx-aware intermediate nodes would not
    be able to view and interpret the CDO, effectively rendering it useless.

REASONING:
Stated the current position and the problem before the solution.
Kept the sentence "an ESP header was used with encryption" to exclude 
the null encryption case.


6. Audit
While I had ConEx state loaded in my brain, I also checked the new Audit 
section.

I thought we agreed we only needed a couple of these sentences in 
section 3 of this doc, not a whole section.
All that has to be done is to specify what will be considered sufficient 
L, E and C signals (another way of saying this is to specify the 
semantics that an audit would reasonably be expected to enforce).
It doesn't have to define what an audit device is or does.

Here's a reminder of the para in conex-abstract-mech [RFC7713-to-be] 
that this spec has to address:
"  The general goal of an auditor is to make sure that any ConEx-enabled
    traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit
    signals.  A concrete definition of the ConEx protocol MUST define
    what sufficient means.
"
You seem to be getting hung up on defining "audit". You only have to 
define "sufficient". You don't even have to mention audit.

IMO, the required definitional sentences should be placed within section 
4, not in an audit section.


<POINTLESS TEXT>
If, despite the above, you do still want an audit section, I started 
correcting it below, before I realised it shouldn't be there at all.

Move these two sentences to the start of the section:
"  This
    document does not mandate a particular audit design. Implementation
    considerations are further discussed in [I-D.wagner-conex-audit].
"

OLD:
An audit element shall be a shadow device in the network, i.e. its
    presence should not be detectable for well-behaving senders.
NEW:
    An audit element will typically be a stealth device in the network,
    i.e. it will not need to notify end systems that discards are due to 
audit failure.

s/senders correctly signals/
  /senders correctly signal/

OLD:
    For this, the audit
    element has to maintain state for any active ConEx-enabled flow.
    Flows must be audited independently, as there are no dependencies.
NEW:
    For this, the audit
    element is likely to have to maintain state for at least a sample of 
active ConEx-enabled flows.
REASONING:
This section is meant to suggest, not mandate, a design.
There is no reason to mandate that flows have to be audited 
independently - so sentence removed.

DELETE this last para:
    The CDO MUST only be used alongside protocols that provide a way to
    audit loss in the network.  Any protocol specification that uses the
    CDO MUST define how an audit device can detect loss on the forward
    path (e.g. sequence number monitoring) and the means for protecting
    against likely attacks on such mechanisms.
REASONING:
conex-abstract-mech already sets all the requirements on other docs that 
address this point.
In particular, the above para contradicts the point in 
conex-abstract-mech that even if the fields of a transport protocol that 
reveal losses are invisible to an audit function, there are still 
reasonable scenarios where audit will work (the "Predominant bottleneck 
loss auditing" case).

</POINTLESS TEXT>



Bob

On 16/12/15 14:08, Kathleen Moriarty wrote:
> Hi Suresh,
>
> On Mon, Dec 14, 2015 at 11:27 PM, Suresh Krishnan
> <[e-mail]> wrote:
>> Hi Kathleen,
>>     I added the text to address the DISCUSSes from you and Stephen. But Mirja
>> and Bob were in the process of reworking text concerning audit and that might
>> lead to some changes to this text. That is why the text has been removed. I
>> am waiting for the new text from Bob/Mirja to send the draft further.
> My leave may start sooner than planned, so if it is possible to get
> this wrapped up today, that would be great.  I don't want this to get
> held up while I am on leave and am not sure when that will start,
> sometime int he next 1-2 weeks.
>
> Thanks!
> Kathleen
>
>> Thanks
>> Suresh
>>
>> On 12/14/2015 09:56 PM, Kathleen Moriarty wrote:
>>> I see the diff has the text added then removed on confidentiality, but
>>> don't see why it was removed.  I'd like to see if we can wrap this up,
>>>    Can you explain why the change that was requested was removed?
>>>
>>> Thanks,
>>> Kathleen
>>>
>>> On Thu, Oct 1, 2015 at 10:43 AM, Bob Briscoe <[e-mail]> wrote:
>>>> Suresh, Kathleen,
>>>>
>>>> (I'm jumping in because I contributed this IPsec section originally)
>>>>
>>>> I think the new sentence about encryption is confusing. It talks about
>>>> authentication of ConEx information, then it says "similarly confidentiality
>>>> of transmitted information might be desired". It needs to be clearer that
>>>> "transmitted information" means the rest of the packet, not the ConEx
>>>> information. Suggested improvements inline...
>>>>
>>>>
>>>> On 01/10/15 02:41, Suresh Krishnan wrote:
>>>>> Hi Kathleen,
>>>>>       Thanks a lot for your comments. Please find responses inline.
>>>>>
>>>>>
>>>>> On 09/30/2015 03:22 PM, Kathleen Moriarty wrote:
>>>>>> Kathleen Moriarty has entered the following ballot position for
>>>>>> draft-ietf-conex-destopt-09: Discuss
>>>>>>
>>>>>> 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/
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> DISCUSS:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> I think this should be easy to address, but wanted to discuss options for
>>>>>> the text in section 7.  Since there is text that says IPsec
>>>>>> Authentication should be used when integrity protection and the section
>>>>>> goes on to also discuss encryption, shouldn't there be a similar
>>>>>> statement that says IPsec encryption should be used when there is a need
>>>>>> to protect confidentiality?
>>>>> Yes. We were worried more about the authentication because tampering of
>>>>> the packet to scrub the markings would cause audit devices to penalize
>>>>> the connection. Encryption on the other hand would be counterproductive
>>>>> as the intermediate nodes would be unable to observe the markings.
>>>>>
>>>>>> Also, in reading this, I think because of the selected wording, I was
>>>>>> thinking that it wasn't clear enough on the need/recommendation for
>>>>>> authentication or encryption with IPsec since there are options for both
>>>>>> to be set to NULL/none.  You can have a NULL cipher-suite and you can
>>>>>> also have authentication set to none to allow for opportunistic security
>>>>>> negotiations (fairly new RFC for the latter).  There's no need to mention
>>>>>> these options explicitly, but rather to make it clear that IPsec can be
>>>>>> used to provide authentication and encryption.  So I think one additional
>>>>>> sentence and some possible rewording in this section would be helpful.
>>>>> I have added a new sentence about encryption and reworded some of the
>>>>> text to clarify. Does this text change work for you?
>>>>>
>>>>> OLD:
>>>>>
>>>>> If the transport network cannot be trusted, IPsec Authentication
>>>>> should be used to ensure integrity of the ConEx information.  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.
>>>>>
>>>>> In IPv6 a Destination Option header can be placed in two possible
>>>>> position in the order of possible headers, either before the Routing
>>>>> header or after the Encapsulating Security Payload (ESP) header
>>>>> [RFC2460].  As the CDO is placed in the destination option header
>>>>> before the AH and/or ESP, it is not encrypted in transport mode
>>>>> [RFC4301].  Otherwise, if the CDO were placed in the latter position
>>>>> and an ESP header were used, the CDO would also be encrypted and
>>>>> could not be interpreted by ConEx-aware devices.
>>>>>
>>>>> NEW:
>>>>>
>>>>> If the transport network cannot be trusted, the IPsec Authentication
>>>>> Header (AH) [RFC4302] should be used to ensure integrity of the ConEx
>>>>> information.
>>>> I suggest this is stated the other way round:
>>>>
>>>> If the transport network cannot be trusted, to ensure integrity of the ConEx
>>>> information the IPsec Authentication Header (AH) [RFC4302] should be used.
>>>>
>>>>
>>>>> 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.
>>>>
>>>>> Similarly, if confidentiality of the transmitted information is desired,
>>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] should be used.
>>>> Suggest replace above sentence with:
>>>>
>>>> If confidentiality of the transmitted packet is desired,
>>>> the IPsec Encapsulating Security Payload (ESP) [RFC4303] can be used,
>>>> However, the CDO header is intended to be visible to
>>>> devices along the path, therefore it will need to be located so that it is
>>>> not
>>>> encrypted as well.
>>>>
>>>>
>>>>
>>>>> Inside an IPv6 packet, a Destination Option header can be placed in two
>>>>> possible positions, either before the Routing header or after the ESP/AH
>>>>> headers as described in Section 4.1 of [RFC2460].  When the CDO is
>>>>> placed in the destination option header before the AH and/or ESP, it is
>>>>> not encrypted in transport mode [RFC4301].  Otherwise, if the CDO were
>>>>> placed in the latter position and an ESP header was used with
>>>>> encryption, the CDO cannot be viewed and interpreted by ConEx-aware
>>>>> intermediate nodes effectively rendering it useless.
>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> For the Security Considerations section, I'd just ask that you add in
>>>>>> "IPsec" when AH and ESP are first mentioned so this is clear.
>>>>> Does the above wording change work to resolve this as well?
>>>>>
>>>>> Cheers
>>>>> Suresh
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> conex mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/conex
>>>>
>>>> --
>>>> ________________________________________________________________
>>>> Bob Briscoe                               http://bobbriscoe.net/
>>>>
>>>
>>>
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/