Subject: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jan 2018 07:34:59 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-mboned-mtrace-v2-22: 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-mboned-mtrace-v2/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The security considerations of this document are inadequate. My review
turns up at least the following potential issues which do
not seem to be addressed or even discussed:

- Amplification: this protocol does not appear to verify that the
  sender of the query actually owns the IP it claims. Because
  responses are much larger than queries, this allows for an amplification
  attack, especially if the client is able to send a query that elicits
  multiple replies. One defense here would be to fill the rest of the packet
  with zeroes, thus somewhat reducing the amplification factor. Access
  control would also help.

- Forgery of responses: because the query id is so short, an attacker
  can generally produce a message which has a nontrivial chance of
  corresponding to an extant query. This could be addressed by having
  a query ID that was large and random.

- Anyone on-path can forge responses.

In addition, Section 9.4 seems inadequate. Isn't it generally the case that
who is sending to who is sensitive? This seems like a fairly serious privacy
obstacle to using this protocol at all.

It seems like many of the issues I raise above would be fixed or at
least mitigated by having some sort of access control mechanism.  I
understand why it might be the case that it's not practical to have
full communication security between the links (though it would of
course be desirable), but it's not clear to me why arbitrary people
should be allowed to instantiate queries.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 1.
   When an Mtrace2 client initiates a multicast trace, it sends an
   Mtrace2 Query packet to the LHR or RP for a multicast group and,

This seems a bit confusing as there are multiple LHRs for the group.
Can you rephrase?

S 2.1.
   ALL-[protocol]-ROUTERS group
      It is a link-local multicast address for multicast routers to

This is grammatically funny. Perhaps remove "It is"

S 3.
   additional information associated with the message.  If an
   implementation receives an unknown TLV type for the first TLV in a
   message (i.e., the header TLV), it SHOULD ignore and silently discard
   the entire packet.  If an implementation receives an unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet.

ISTM that these cases are handled identically so is there a reason
not just to remove the first sentence and change the second one to
"for any TLV"/

S 3.2.1
   An Mtrace2 Query is usually originated by an Mtrace2 client which
   sends an Mtrace2 Query message to the LHR.  When tracing towards the
   source or the RP, the intermediate routers MUST NOT modify the Query
   message except the Type field.

I'm not sure I follow this. Don't routers either (a) not touch this at all
or (b) if they are the LHR, change Type from Query -> Request and then
add a response block? This text seems to not really capture either case.

S 3.2.4.
      Note that Mtrace2 does not require all the routers on the path to
      have synchronized clocks in order to measure one-way latency.

It's not clear to me how one does this. Can you expand?

S 3.2.6.

          0x01    # of the returned Standard Response Blocks

Nit: Do you want to say 0x0001

Also, an example of the case covered by this section would help, I think.

S 4.4.
It might be clearer to move this up a bit in the text as it sort of
summarizes some cases you already covered before. It would be easier
if it provided an overview instead.

S 5.9.

   In this case, the Mtrace2
   client may receive multiple Mtrace2 Replies from different routers
   along the path.  When this happens, the client MUST treat them as a
   single Mtrace2 Reply message.

Can you please describe how the client reassembles multiple messages
into one. I think I may know how to do this, but the document should
tell me.

S 8.
   The following new registries are to be created and maintained under
   the "RFC Required" registry policy as specified in [4].

Why did you choose RFC Required rather than Specification Required?
This just seems to unduly put load on the ISE.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Jan 2018 20:31:49 +0100

Thanks, Eric

Just voicing my personal opinions, hopefully helpfull to resolve the issues.

A) Rant

> it's not clear to me why arbitrary people should be allowed to instantiate queries.

Because 25 years experience of multicast geeks has been the network operators have
been incapable or unwilling to diagnose multicast, so users had to help users.

[no comment needed]

B) solution proposals

> least mitigated by having some sort of access control mechanism.

Right. But 9.2 already says as much, so whats the minimum (weakest)
better form of filtering that you would approve of to resolve your issues ?

I would suggest three points:

B.1) deny third-party mtrace for user devices by default

| Mtrace queries SHOULD by default only be processed when sent with a source
| address directly connected to the interface on which it is received. They
| MAY additionally be filtered by the presence of IGMPv3/MLDv2 explicitly
| tracked receiver state for the indicated multicast traffic (group {,source})
| from the source address.

This would still leave the gap of source address spoofing within a subnet,
but we have IMHO ample precedent how the IETF leaves this problem to
subnet mechanisms like L2 switch IP/MAC binding (e.g.: no protection against
this in most DHCP, IGMP/MLD, PIM, ...).

B.2) explicit permitting third-party mtrace only to trusted (OAM equipment) originators

The existing 9.2. text IMHO already says that you need to support ACLs
to filter queries. Maybe add/replace with text being more specific about the
intended deployment scenario:

| Beyond (or instead of) directly connected addresses, Mtrace queries MUST only be
| processed through administratively established filtering from source IP addresses
| that are known not to be spoofed and that are known to be authorized to receive the
| conveyed (third party) multicast information. For example, professionally managed
| networks typically have addresses ranges assigned to (subsets of) network OAM 
| equipment that is also protected from address spoofing through filtering on the network
| edge.

  [ _how_ to define that filtering is hopefully something we can leave off to
    a future  companion document "yang model for mtrace", because some details
    might be tricky:
     - amend and/or superceed the "connected IP address" rule
     - rule for "internal" operator addresses (e.g.: from BGP attributes)
       vs. non-permitted "customer" addresses ]

B.3) Expectation/setup of non on-path spoofing between third-party
     (OAM device) query initiator and responder.
    
The third part seems to be setting expectations straight for mtrace originators,
not sure if this should go into 5.1 (sending mtrce query) or 9. (security).

| Originators of mtrace queries are not protected against spoofed replies.
| They should therefore only originate Mtrace queries to addresses for
| whom they can assume reasonable protection against spoofing:
| 
| - User equipment should send mtrace queries only to known default
|   router addres(es) on its connected LANs. This is more secure than
|   sending to all-routers address because it minimizes the opportunity
|   for spoofing of replies by other nodes on the subnet  (in the absence
|   of subnet specific mechanisms to protect against that attack).
| 
| - Network OAM equipment (permitted as sources for Mtrace queries through
|   administrative action as explained in 9.2) should send mtrace queries
|   only to destination addresses of network equipment for whom spoofing
|   of replies along the path is not an attack vector. Typically this is the
|   same set of devices administratively configured to permit this Mtrace
|   originators requests.
  
Give or take the wording, but would these three items if worded according
resolve your discuss ? To re-summarize:

  B.1) deny third-party mtrace for user devices by default
  B.2) explicit permitting third-party mtrace only to trusted
       (OAM equipment) originators
  B.3) Expectation/setup of non on-path spoofing between third-party
       (OAM device) query initiator and responder.

C) I hate address filtering security, but given how this has been a
protocol waiting for 20++ years for an RFC i don't think we should
muck around with the protocol now and further delay it. Aka: as
nice-to-have larger query-ids would be - is it worth doing this
protocol change now given the above security model ?

The most likely next step to overcome the trusted path issue between
query initiator to query responder is to make an mtrace yang model where
you can actually initiate an mtrace via netconf/yang, aka: replace
the query with netconf. Like you would today just ssh into the
LHR and run a local mtrace client there.

Alas, i see no easy way to get back to support A) in a lightweight
fashion ;-(

Cheers
    Toerless

On Thu, Jan 18, 2018 at 07:34:59AM -0800, Eric Rescorla wrote:
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 23 Jan 2018 23:57:05 +0900

Dear Eric,

Thank you for your comments.

We, authors, understand your thoughts.
However, as Toerless mentioned (thanks Toerless for explaining our thoughts), we believe this document already provides the basic security requirements for the mtrace specification itself.
We might say many of these security concerns would be discussed and addressed for IP multicast in general or with more specific model and mentioned in other documents.
But of course, we will clarify or explain in the revised draft if necessary and can see if you accept the explanation or not.

Thanks for your opinion.

Best regards,

Hitoshi

> 2018/01/20 4:31, Toerless Eckert <[email-masked]> wrote:
> 
> Thanks, Eric
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jan 2018 14:20:10 -0800

> been incapable or unwilling to diagnose multicast, so users had to help

This doesn't seem like a good reason to create significant security issues
for the rest of the Internet.

> better form of filtering that you would approve of to resolve your issues ?

I don't know yet. At the moment I'm at the point where the security analysis
of this document seems severely lacking (as evidenced by my so easily
finding issues that weren't addressed) so I'm not sure what appropriate
resolutions would be.

> this in most DHCP, IGMP/MLD, PIM, ...).

I think the key point here is that this is not solely about unauthorized
access
but also about amplification. To expand on that point, another source of
potential
amplification is to inject a Request but to lie about the requesting
address,
thus causing the final router to send a big response.

> protocol change now given the above security model ?

I'm not sure how long this is waiting is really that persuasive an argument
against doing the right thing. We know addresses are untrustworthy and
it's not like I'm suggesting you introduce real comsec between the
endpoints (though some form of real authentication would clearly be
better).

-Ekr

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jan 2018 23:33:35 +0100

Thanks Eric, inline

> for the rest of the Internet.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I should say "no comment", but actually, this could help to consider:

Please tell me a place (ISP) where i can get residential IP Multicast across
the Internet so i can move there.

Aka: 99.9% of IP Multicast is deployed in controlled networks. 99.9% of
IP multicast application traffic is failing IETF congestion control requirements
and does not care because they operate in controlled networks. If you have
any market investing, your financial gains likely depend on non
IETF congestion control compliant IP multicast trading traffic.

Aka: not my preference (i have written my preferences in B.1/2/3), but if we are
not coming up with any better security scoping, we might consider scoping
mtrace to controlled networks because it would effectively not limit its
deployment much at all.

> access  but also about amplification. To expand on that point, another source of
> potential  amplification is to inject a Request but to lie about the requesting
> address,  thus causing the final router to send a big response.

My point B.1) explicitly disables lying about the requesting address, so it is
explicitly meant to prohibit amplification attacks. 

(give or take the subnet local limitations and/or additional L2 security
 required to prohibit intra-l2-lying that i mentioned in my original mail).

> least mitigated by having some sort of access control mechanism. 

My points B.1, B.2, B.3) provide solid access control mechanisms for
mtrace using mechanisms that are the most widely adopted form of security in ISPs
and that this option of security in mtrace should not be dismissed just because
it took us so long to bring the protocol in front of IESG review even if we agree
that we should have better options beyond that.

The other point was that better security options are something we should not
invent as one-off protocol hack sinto mtrace (even if some mtrace none request/reply
messages might be fun to define) but instead we should adopt solutions that are more
likely in-line with existing network OAM security strategies. TLS connections,
netconf/yang etc. pp. As i described in my email.

Cheers
    toerless

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jan 2018 15:08:58 -0800

> explicitly meant to prohibit amplification attacks.

I don't see how that's true. The attack I am concerned about is that you
forge
a *Request*, not a *Query*. And because the request indicates the original
requester.

>  required to prohibit intra-l2-lying that i mentioned in my original mail).

Sorry, I'm not seeing this. The point is that you pretend to be a router
that is forwarding a Request and fill in a bogus Client Address field. Waht
stops that.

> that we should have better options beyond that.

The question is whether those options are in fact adequate. For the reasons
above I don't believe that.

-Ekr

> > > > In addition, Section 9.4 seems inadequate. Isn't it generally the
> case
> > > that
> > > > I'm not sure I follow this. Don't routers either (a) not touch this
> at
> > > all

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2018 02:31:18 +0100

On Thu, Jan 25, 2018 at 03:08:58PM -0800, Eric Rescorla wrote:
> > My point B.1) explicitly disables lying about the requesting address, so
> > it is explicitly meant to prohibit amplification attacks.
> >
> 
> forge a *Request*, not a *Query*. And because the request indicates the original
> requester.

Ah, sorry. I thought to remember that the text from you said query.
I just replied for query messages so far.

> that is forwarding a Request and fill in a bogus Client Address field. Waht

In practical deployments IMHO we can only reasonable get similar solutions to
what customer are also willing to deploy with PIM. For 99% deployments that
is configured classificatio of interfaces as trusted/inside-clamshell or
untrusted/user-facing, and on the untrusted interfaces you don't accept
requests, just queries. And apply the suggested B.1 policy (Mtracev2 Client
Address must be connected on receiving interface).

It might still be useful to have mtrace prepared for customers protecting it
with IPsec - without requiring special features in mtrace or IPsec for it.

IMHO for that, we need to have one UDP port for mtrace NNI messages
(requests), and another for UNI messages (query, response).
That would allow customers to take a vanilla IPsec implementation and protect
the mtrace NNI messages and therefore eleiminate interface clamshell
classification.  In multicast signaling we got this for free: PIM is NNI,
IGMP/MLD UNI. Easy to distinguish for IPsec.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2018 19:22:43 +0100

> I just replied for query messages so far.
                     ^^^^^
*sigh* "request" of course.

Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jan 2018 13:58:04 -0800

Hi Toerless,

I appreciate the solution thinking, but I don't want to overrotate on these
specific threats (though of course we must address them). My concern is
that if there are threats this obvious then we need a more complete threat
analysis. I.e., what are the avenues for attack with this protocol and then
what mechanisms prevent those things. The purpose of the security
considerations section is to make sure that that happens. Has someone done
that somewhere and it just didn't make it into the document?

-Ekr

On Thu, Jan 25, 2018 at 5:31 PM, Toerless Eckert <[email-masked]> wrote:

> > > mtrace using mechanisms that are the most widely adopted form of
> security
> > > in ISPs
> > > it took us so long to bring the protocol in front of IESG review even
> if
> > > we agree
> > > The other point was that better security options are something we
> should
> > > not
> > > > > > email addresses included in the To and CC lines. (Feel free to
> cut
> > > this
> > > > > >   multiple replies. One defense here would be to fill the rest
> of the
> > > > > packet
> > > > > > who is sending to who is sensitive? This seems like a fairly
> serious
> > > > > privacy
> > > > > >    the entire packet.  If an implementation receives an unknown
> TLV
> > > type
> > > > > >    sends an Mtrace2 Query message to the LHR.  When tracing
> towards
> > > the
> > > > > > add a response block? This text seems to not really capture
> either
> > > case.
> > > > > >
> > > > > >
> > > > > > S 3.2.4.
> > > > > >       Note that Mtrace2 does not require all the routers on the
> path
> > > to
> > > > > > Also, an example of the case covered by this section would help,
> I
> > > think.
> > > > > >
> > > > > >
> > > > > >
> > > > > > S 4.4.
> > > > > >    along the path.  When this happens, the client MUST treat
> them as
> > > a