Re: [secdir] secdir review of draft-ietf-mpls-rfc6374-udp-return-path

Stewart Bryant <> Thu, 07 April 2016 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 042FD12D509; Thu, 7 Apr 2016 07:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7DN2uHH_dB6G; Thu, 7 Apr 2016 07:16:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 447BE12D11E; Thu, 7 Apr 2016 07:16:21 -0700 (PDT)
Received: by with SMTP id f198so27545288wme.0; Thu, 07 Apr 2016 07:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OGm9FawcCOXJ8KKaaMB/J3+zFMRN4ogtBityMlMeuCU=; b=Q0/oU25aNvx50Zf+xf6WnB/Sg7mgUoT4EOeav/x12u9cxdn5CZSUUJ2v2jocShPzP2 6RsezXeStbtWnVca+7ZI30CvQxkZrO8TptApfcjT9mygumStoXbUbzajtNgrcK2P1NIA //hlcuUAtdynhkybVCvpkFwwmEufSM69Fn63V2FW/ohwr65XYDKs7vZvVaTrkNurCykz iXS7FKwDrlL2obAzawfRl5Nbg7TYNNJsZgleHmJJ9B8hkihnJCFE+15Wz8n7AZam13gd nEJZEsImLLopKpxbWT0Sq2Ag1pZYk3dlEHhVKIbWcw629DKNnpscIVZFPVGmTac8zuhS OfFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OGm9FawcCOXJ8KKaaMB/J3+zFMRN4ogtBityMlMeuCU=; b=FBtjj2DxtG856ormxyum6asKA1JWfPZ3DoBA8Vc4LmvH4OAnBn0Dwa7yZSigGJ6+2H 5NU4GXLAgPv5fEo/DzXbkYNeuzXkiDNuiR0RZIe7qJRUNn0qvO7ylHJ6hyaqmrZUhLpQ Iy21vQMcJId4v4upk2/KPRYP2OPT8ZyyWxFSSHelZFJdysrcdTKVCedKqwjeriyFRwHJ 6DHreKx6oX7FtlS9i+Xp47BZZy4/me133j9d8uRrSh5Etbl4UXLeJtetdHnZsMc0MkHX TzRDHLLowf5/4W/9dfIwqR+CuNc3rP9hJ36a5XrjQzFyZjl48SxMIde97KYJKklcAQEr RAOA==
X-Gm-Message-State: AD7BkJKwtngVQs2jZP/ctTqQxdCk4wDGvSHw8J0Jm+UiY+s9v+In2GEmESBEra1YQ2uoyQ==
X-Received: by with SMTP id 125mr30784815wml.58.1460038579755; Thu, 07 Apr 2016 07:16:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w193sm3506495wmd.0.2016. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 07:16:18 -0700 (PDT)
To: Sandra Murphy <>,, The IETF <>,
References: <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 7 Apr 2016 15:16:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-mpls-rfc6374-udp-return-path
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Apr 2016 14:16:32 -0000

On 18/12/2015 09:57, Stewart Bryant wrote:

Sandy, I have looked at this discussion again. Please see inline:
>> Section 4.2
>>   If an Out-of-band response is requested and the Address object or the
>>   URO is missing, the query SHOULD be dropped in the case of a
>>   unidirectional LSP.  If both these TLVs are missing on a
>>   bidirectional LSP, the control code of Response message should set to
>>   0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and
>>   the response SHOULD be sent over the reverse LSP.  The receipt of
>>   such a mal-formed request SHOULD be notified to the operator through
>>   the management system, taking the normal precautions with respect to
>>   the prevention of overload of the error reporting system.
>> The first sentence says that both the Address object and the URO must
>> be present or the query is dropped - right?  I'm reading this as
>>       (if not(Address) OR not(URO)) then drop.
>> What Address object - there are three - Return, Source and
>> Destination.  I'm betting on Return, but the text should be clear.
> That is return address - I will update the text.

Looking at the text again, since we are ONLY talking about systems using 
URO, the Address object text fragment is pointless so I have deleted it.

>> The RFC6374 out-of-band response feature and the "Return Address"
>> object seem to indicate the potential exists in RFC6374 as well.
>> RFC6374's security consideration section does not mention the
>> reflection attack possibility, only the integrity of the return
>> out-of-band path and the possibility of affecting the validity of the
>> measurements.  But even if the assumptions of well-managed, private,
>> service provider networks are met, I believe that the potential and
>> increased need for careful configuration should be mentioned. "Note:
>> the feature can be misused, so take care".  Perhaps a manageability
>> section caution about checking the Return Address or URO to ensure
>> addresses are within the private or service provider network.
>> something?  Or presume all will be well, because this is to be used in
>> well managed private and service provider networks?
> I will look at adding some text, although the assumption is that
> MPLS networks are well managed, and there are many other ways
> they would break if they were not.

This text is only about the URO case. The only residual text on the DA obj
is in the section that is to be deleted.

- Stewart