Subject: [Isis-wg] Genart last call review of draft-ietf-isis-auto-conf-04

From: Robert Sparks <[email-masked]>
Date: Fri, 07 Apr 2017 13:24:52 -0700

Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-isis-auto-conf-04
Reviewer: Robert Sparks
Review Date: 2017-04-07
IETF LC End Date: 2017-04-10
IESG Telechat date: 2017-04-13

Summary: Ready for publication as Proposed Standard, but with 
one possible thing to add to the security consideration section

This document is clear and seems straightforward to implement. 

I think, however, there is an attack possibility you should call out 
in the security considerations section. As home routers are used 
as examples of elements that might use this protocol, consider 
the case of a malicious party wanting to deny service in that home.
A suborned device in the home could watch for the protocol, and
present a crafted packet to force the home router(s) to re-start
the autoconfiguration protocol continually (by claiming to be a
duplicate and being careful to make it the routers job to restart).
Having the md5 password configured would mitigate this attack.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Apr 2017 20:55:38 +0000

Robert -

Thanx for the review.
Reply inline.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Friday, April 07, 2017 1:25 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> Reviewer: Robert Sparks
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> Summary: Ready for publication as Proposed Standard, but with one possible
> thing to add to the security consideration section
> 
> I think, however, there is an attack possibility you should call out in the
> security considerations section. As home routers are used as examples of
> elements that might use this protocol, consider the case of a malicious party
> wanting to deny service in that home.
> A suborned device in the home could watch for the protocol, and present a
> crafted packet to force the home router(s) to re-start the autoconfiguration
> protocol continually (by claiming to be a duplicate and being careful to make
> it the routers job to restart).

[Les:] The draft says two things which are relevant:

3.5.1.  Authentication TLV

   It is RECOMMENDED that IS-IS routers supporting this specification
   offer an option to explicitly configure a single password for HMAC-
   MD5 authentication as specified in[RFC5304].

4.  Security Considerations

   In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration.

It seems to me that these sections adequately cover your point.
???

    Les

---

From: Robert Sparks <[email-masked]>
Date: Fri, 7 Apr 2017 16:17:59 -0500

> It seems to me that these sections adequately cover your point.
They provide the mitigation. They do not call out the risk.

The current security considerations section says for wired networks, 
plugging into the wire is protection enough, and you don't need to use 
the authentication tlv.  I don't think that's true given the possibility 
of this attack. I suggest discussing the attack in the security 
considerations section and pointing to using the Authentication TLV with 
it's onerous bit of manual configuration as the mitigation.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Apr 2017 21:30:14 +0000

Robert -

> Sent: Friday, April 07, 2017 2:18 PM
> To: Les Ginsberg (ginsberg); [email-masked]
> Subject: Re: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> 
> 
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> Summary: Ready for publication as Proposed Standard, but with one
> >> possible thing to add to the security consideration section
> >>
> >> in the security considerations section. As home routers are used as
> >> examples of elements that might use this protocol, consider the case
> >> of a malicious party wanting to deny service in that home.
> >> present a crafted packet to force the home router(s) to re-start the
> >> autoconfiguration protocol continually (by claiming to be a duplicate
> >> and being careful to make it the routers job to restart).
> The current security considerations section says for wired networks, plugging
> into the wire is protection enough, and you don't need to use the
> authentication tlv.  I don't think that's true given the possibility of this attack.
> I suggest discussing the attack in the security considerations section and
> pointing to using the Authentication TLV with it's onerous bit of manual
> configuration as the mitigation.
> 
[Les:] If you insist I am OK with this - but frankly you are twisting my arm. :-)
System-id duplication is a problem for any deployment - not just autoconfig deployments. And it will be disruptive in any network until it is resolved.
The only thing autoconfig has added is a way to resolve this w/o manual intervention. This in no way increases the vulnerability nor the disruption the attacker can produce. (Yes - I state that quite intentionally).
So you are asking us to repeat a discussion which has already been held in the context of RFC 5304 and RFC 5310.

It would be more appropriate to add the normal reference to RFC 5304/5310 in the Security section than what you propose.

   Les

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 7 Apr 2017 21:44:37 +0000

On 4/7/17, 5:30 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Les:

Hi!

> System-id duplication is a problem for any deployment - not just autoconfig 
> deployments. And it will be disruptive in any network until it is resolved.
>
> The only thing autoconfig has added is a way to resolve this w/o manual 
> intervention. This in no way increases the vulnerability nor the disruption the 
> attacker can produce. (Yes - I state that quite intentionally).

I don’t know about Robert, but that is part of the discussion I would like to see.

Yes, duplicate system-ids have always been a potential problem, but this document introduces a new de-duplication mechanism that results not just in unsync’d databases, but in restarting adjacencies – so at least the manifestation of the problem is different.

> Security section than what you propose.

I don’t think it hurts to add a reference to those RFCs, but they are both about adding authentication – the problem in this document is exacerbated by the fact that there’s no authentication by default.

The lower layer authentication mechanisms are quite weak, specially knowing that, if in a home environment, for example, it may be relatively easy to connect to the WiFi network.

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Apr 2017 22:44:25 +0000

Alvaro -

Not sure how long we should debate this as the text you are asking for is modest - but one more attempt on my part - not so much to debate whether to add text or not - but to come to a common understanding.

> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 2:45 PM
> To: Les Ginsberg (ginsberg); Robert Sparks; [email-masked]
> > System-id duplication is a problem for any deployment - not just
> > autoconfig deployments. And it will be disruptive in any network until it is
> resolved.
> >
> > The only thing autoconfig has added is a way to resolve this w/o
> > manual intervention. This in no way increases the vulnerability nor
> > the disruption the attacker can produce. (Yes - I state that quite
> intentionally).
> 
> Yes, duplicate system-ids have always been a potential problem, but this
> document introduces a new de-duplication mechanism that results not just
> in unsync’d databases, but in restarting adjacencies – so at least the
> manifestation of the problem is different.
> 
[Les:] The "problem" exists as long as the duplicate system-ids exist. The recovery mechanism does not introduce new problems - it actually acts to minimize the duration of the problem. One could argue (and I am NOT doing so) that automated resolution could be a benefit in all deployments. I think the issue in non-autoconfig deployments is that since systems have been manually provisioned we cannot assume that network operators want us to automatically change the config on one of their boxes. Though, who knows - maybe we will get asked to use this extension outside of autoconfig deployments. 

It is necessary to have such a mechanism in autoconfig deployments since there is - by default - no manual intervention. But to characterize this as adding risk is incorrect IMO.

  Les

> > So you are asking us to repeat a discussion which has already been
> > held in the context of RFC 5304 and RFC 5310.
> >
> > It would be more appropriate to add the normal reference to RFC
> > 5304/5310 in the Security section than what you propose.
> 
> I don’t think it hurts to add a reference to those RFCs, but they are both
> about adding authentication – the problem in this document is exacerbated
> by the fact that there’s no authentication by default.
> 
> The lower layer authentication mechanisms are quite weak, specially
> knowing that, if in a home environment, for example, it may be relatively
> easy to connect to the WiFi network.
> 
> Alvaro.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 10 Apr 2017 10:07:10 +0000

Hi Rober, Alvaro, and Les,

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Sent: Saturday, April 08, 2017 6:44 AM
> To: Alvaro Retana (aretana); Robert Sparks; [email-masked]
> Subject: RE: Genart last call review of draft-ietf-isis-auto-conf-04
> 
> Alvaro -
> 
> Not sure how long we should debate this as the text you are asking for is
> modest - but one more attempt on my part - not so much to debate whether
> to add text or not - but to come to a common understanding.
> 
> > Yes, duplicate system-ids have always been a potential problem, but
> > this document introduces a new de-duplication mechanism that results
> > not just in unsync’d databases, but in restarting adjacencies – so at
> > least the manifestation of the problem is different.
> >
> [Les:] The "problem" exists as long as the duplicate system-ids exist. The
> recovery mechanism does not introduce new problems - it actually acts to
> minimize the duration of the problem. One could argue (and I am NOT doing
> so) that automated resolution could be a benefit in all deployments. I think
> the issue in non-autoconfig deployments is that since systems have been
> manually provisioned we cannot assume that network operators want us to
> automatically change the config on one of their boxes. Though, who knows -
> maybe we will get asked to use this extension outside of autoconfig
> deployments.
> 
> It is necessary to have such a mechanism in autoconfig deployments since
> there is - by default - no manual intervention. But to characterize this as
> adding risk is incorrect IMO.

[Bing] I agree with Les that sys-id duplication attack is not an "adding" risk. 
But maybe we could add a bit more text to explain why this document RECOMMNED to implement Auth TLV.

Proposed added text in 3.5.1 (Authentication TLV) as below:
"The use of authentication is incompatible with auto-configuration as it requires some manual configuration. However, there might be some users would like to pay the effort of manual configuration to mitigate some security attack (e.g. a malicious node crafts packet to intentionally cause the Sys-ID duplication procedure continuously). 
Thus, it is RECOMMENED that IS-IS... (the same as existing text).

Do you think it's OK?

Best regards,
Bing

> > I don’t think it hurts to add a reference to those RFCs, but they are
> > both about adding authentication – the problem in this document is
> > exacerbated by the fact that there’s no authentication by default.
> >
> > knowing that, if in a home environment, for example, it may be
> > relatively easy to connect to the WiFi network.
> >
> > Alvaro.
> >

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 10 Apr 2017 14:16:17 +0000

Les:

Hi!

The risk is not in the mechanism itself, assuming two routers with the correct implementation.

The risk is in the fact that a compromised router can craft a packet to force the auto-config routers to continuously restart.   All we’re asking for is a recognition that the risk exists.

Thanks!

Alvaro.

On 4/7/17, 6:44 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Alvaro -

  Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Apr 2017 14:34:20 +0000

Bing/Robert/Alvaro -

Here is the existing text of the Security Section:

  "In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration.

   For wired deployment, the wired connection itself could be considered
   as an implicit authentication in that unwanted routers are usually
   not able to connect (i.e. there is some kind of physical security in
   place preventing the connection of rogue devices); for wireless
   deployment, the authentication could be achieved at the lower
   wireless link layer."

Proposed revision:

"In the absence of cryptographic authentication it is possible for an attacker to inject  a PDU falsely indicating
 there is a duplicate system-id. This may trigger automatic restart of the protocol using the duplicate-id
resolution procedures defined in this document. 

Note that the use of authentication is incompatible with auto-
configuration as it requires some manual configuration.

   For wired deployment, the wired connection itself could be considered
   as an implicit authentication in that unwanted routers are usually
   not able to connect (i.e. there is some kind of physical security in
   place preventing the connection of rogue devices); for wireless
   deployment, the authentication could be achieved at the lower
   wireless link layer."

???

   Les

> From: Liubing (Leo) [mailto:[email-masked]]
> Sent: Monday, April 10, 2017 3:07 AM
> To: Les Ginsberg (ginsberg); Alvaro Retana (aretana); Robert Sparks; gen-
> [email-masked]
> > Not sure how long we should debate this as the text you are asking for
> > is modest - but one more attempt on my part - not so much to debate
> > whether to add text or not - but to come to a common understanding.
> >
> > > > manual intervention. This in no way increases the vulnerability
> > > > nor the disruption the attacker can produce. (Yes - I state that
> > > > quite
> > > intentionally).
> > >
> > > not just in unsync’d databases, but in restarting adjacencies – so
> > > at least the manifestation of the problem is different.
> > >
> > [Les:] The "problem" exists as long as the duplicate system-ids exist.
> > The recovery mechanism does not introduce new problems - it actually
> > acts to minimize the duration of the problem. One could argue (and I
> > am NOT doing
> > so) that automated resolution could be a benefit in all deployments. I
> > think the issue in non-autoconfig deployments is that since systems
> > have been manually provisioned we cannot assume that network
> operators
> > want us to automatically change the config on one of their boxes.
> > Though, who knows - maybe we will get asked to use this extension
> > outside of autoconfig deployments.
> >
> > It is necessary to have such a mechanism in autoconfig deployments
> > since there is - by default - no manual intervention. But to
> > characterize this as adding risk is incorrect IMO.
> 
> "The use of authentication is incompatible with auto-configuration as it
> requires some manual configuration. However, there might be some users
> would like to pay the effort of manual configuration to mitigate some
> security attack (e.g. a malicious node crafts packet to intentionally cause the
> Sys-ID duplication procedure continuously).
> > > I don’t think it hurts to add a reference to those RFCs, but they
> > > are both about adding authentication – the problem in this document
> > > is exacerbated by the fact that there’s no authentication by default.
> > >

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 10 Apr 2017 17:32:27 +0000

Works for me!

Thanks!

Alvaro.

On 4/10/17, 10:34 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Bing/Robert/Alvaro -

Proposed revision:

???

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Apr 2017 13:35:39 -0400

+1

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 11 Apr 2017 01:44:40 +0000

Hi Les, Robert and Alvaro,

Thanks for Les' proposed text. I'll update it accordingly.

B.R.
Bing

> Sent: Tuesday, April 11, 2017 1:36 AM
> To: Alvaro Retana (aretana); Les Ginsberg (ginsberg); Liubing (Leo);
> [email-masked]
> > "In the absence of cryptographic authentication it is possible for an
> > attacker to inject  a PDU falsely indicating there is a duplicate
> > system-id. This may trigger automatic restart of the protocol using the
> duplicate-id resolution procedures defined in this document.
> >