[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: 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-opsawg-mud/



--
DISCUSS:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as an access control mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>https://example.com/lightbulbs/colour/v1
>
>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>-in mudfile -binary -outform DER - \
>-certfile intermediatecert -out mudfile.p7s
>
>  Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


--
COMMENT:
--


>
>   Abstract
>
>  This memo specifies a component-based architecture for manufacturer
>  usage descriptions (MUD).  The goal of MUD is to provide a means for
>  Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>  it continues to make sense for general purpose computing devices
>  today, including laptops, smart phones, and tablets.
>
>  [RFC7452] discusses design patterns for, and poses questions about,
>  smart objects.  Let us then posit a group of objects that are
>  specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>  specifically not general purpose computers.  These devices, which
>  this memo refers to as Things, have a specific purpose.  By
>  definition, therefore, 

[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-opsawg-mud-20: 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-opsawg-mud/



--
DISCUSS:
--

Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>https://example.com/lightbulbs/colour/v1
>
>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>-in mudfile -binary -outform DER - \
>-certfile intermediatecert -out mudfile.p7s
>
>  Note: A MUD file may need to be re-signed if the signature expires.
>
>   12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.


--
COMMENT:
--


>
>   Abstract
>
>  This memo specifies a component-based architecture for manufacturer
>  usage descriptions (MUD).  The goal of MUD is to provide a means for
>  Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>  it continues to make sense for general purpose computing devices
>  today, including laptops, smart phones, and tablets.
>
>  [RFC7452] discusses design patterns for, and poses questions about,
>  smart objects.  Let us then posit a group of objects that are
>  specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>  specifically not general purpose computers.  These devices, which
>  this memo refers to as Things, have a specific purpose.  By
> 

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Douglas Gash (dcmgash)]

Hello Opsawg,

We have uploaded a new version of the TACACS+ informational draft which 
includes corrections for typos over the document as a whole, but also revised 
the security section. We anticipate this security section will get most 
comments, so it is reproduced below.

We will endeavor to be much more reactive to comments, whether on section 
below, or any other in rest of uploaded document.

Many thanks,

The authors.



9.  TACACS+ Security Considerations

   The original TACACS+ Draft[1] from 1998 did not address all of the
   key security concerns which are considered when designing modern
   standards.  This section addresses known limitations and concerns
   which will impact overall security of the protocol and systems where
   this protocol is deployed to manage central authentication,
   authorization or accounting for network device administration.

   Multiple implementations of the protocol described in the draft[1]
   have been deployed.  As the protocol was never standardized, current
   implementations may be incompatible in non-obvious ways, giving rise
   to additional security risks.  This section does not claim to
   enumerate all possible security vulnerabilities.

9.1.  General Security of The Protocol

   TACACS+ protocol does not include a security mechanism that would
   meet modern-day requirements.  Support for MD5-based crypto pad
   encryption fails to provide any kind of transport integrity, which
   presents at least the following risks:

  Accounting information may be modified by the man-in-the-middle
  attacker, making such logs unsuitable and untrustable for auditing
  purposes.

  Only the body of the request is encrypted which leaves all header
  fields open to trivial modification by the man-in-the-middle
  attacker.  For this reason, connections with
  TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the
  recommendations section.

  Invalid or misleading values may be inserted by the man-in-the-
  middle attacker in various fields at known offsets to try and
  circumvent the authentication or authorization checks even inside
  the encrypted body.

   While the protocol provides some measure of transport privacy, it is
   vulnerable to at least the following attacks:

  Brute force attacks exploiting increased efficiency of MD5 digest
  computation.

  Known plaintext attacks which may decrease the cost of brute force
  attack.

  Chosen plaintext attacks which may decrease the cost of a brute
  force attack.

  No forward secrecy.

   Even though, to the best knowledge of authors, this method of
   encryption wasn't rigorously tested, enough information is available
   that it is best referred to as "obfuscation" and not "encryption".

   For these reasons, users deploying TACACS+ protocol in their
   environments MUST limit access to known clients and MUST control the
   security of the entire transmission path.  Attacks who can guess the
   key or otherwise break the obfuscation will gain unrestricted and
   undetected access to all TACACS+ traffic.  Ensuring that a
   centralized AAA system like TACACS+ is deployed on a secured
   transport is essential to managing security risk of such an attack.

   The following parts of this section enumerate only the session-
   specific risks which are in addition to general risk associated with
   bare obfuscation and lack of integrity checking.

9.2.  Security of Authentication Sessions

   Authentication sessions SHOULD NOT be used via insecure transport as
   the man-in-the-middle attack may completely subvert them.  Even CHAP,
   which may be considered resistant to password interception, is unsafe
   as it does not protect the username from a trivial man-in-the-middle
   attack.

   This document deprecates the redirection mechanism using the
   TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
   original draft.  As part of this process, the secret key for a new
   server was sent to the client.  This public exchange of secret keys
   means that once one session is broken, it may be possible to leverage
   that key to attacking connections to other servers.  This mechanism
   SHOULD NOT be used in modern deployments.  It MUST NOT be used
   outside a secured deployment.

9.3.  Security of Authorization Sessions

   Authorization sessions MUST be used via secure transport only as it's
   trivial to execute a successful man-in-the-middle attacks that
   changes well-known plaintext in either requests or responses.

   As an example, take the field "authen_method".  It's not unusual in
   actual deployments to authorize all commands received via the device
   local serial port (a console port) as that one is usually considered
   secure by virtue of the device located in a physically secure
   location.  If an administrator would configure the authorization
   system to allow all commands entered by the user on a 

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Randy Bush]

> I do not see any indication of wide-spread consistency.

the point is that there is widespread use.  the page heas pointed out is
what is documented by large ops, the tip of the iceberg.  how about stop
speaking for operators?

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[li zhenqiang]

Dear Joel Halpern,

Thank you very much for your review. Please see my preliminary reply below.

For your first concern, the idea is when the routers obtain the information for 
the already defined BGP related IEs, such as bgpSourceAsNumber, 
bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc, the information for the 
IEs defined in this doc can be obtained at the same time since all the BGP 
related information of a flow is obtained from the matching BGP routing entry 
when the router receives the first packet of the flow. We explain this point in 
the forth paragraph of the Introduction part. Our co-author Jie Dong, who is 
from product vendor Huawei, will explain this in more detail later.

I do NOT think the routers have to change their architectures to report the BGP 
related information for the traffic flow. Supposing the routers have to do 
this, they have already done so when implementing the already defined BGP 
related IEs bgpSourceAsNumber, bgpDestinationAsNumber, and 
bgpNextHopIPv4Address, etc. The first BGP related information element is not 
defined by our draft.

We admit that the correlation could be done at the collectors. But we insist 
that the right place to do the BGP related correlation is the exporters in the 
routers, because the correlation for the BGP related information is very heavy 
for the collectors. To do so, the collectors have to run BGP or BMP which is 
already running in the routers and to do BGP table longest prefix matching 
lookup to find the correct table entry. We explain this point in the 4th and 
5th paragraphs of the Introduction part.

For your second concern, you admit using BGP community attribute to represent 
the geographical regions and different kinds of customers is a legal practice, 
so said in RFC4383 and RFC8195.  Why do you think this is unusual and not 
common? China Mobile uses the standard BGP community to represent the different 
provinces and different kinds of customers in our field network. Swisscom and 
AT also said this doc was useful for their network operation in the mail list 
and face to face meeting. Anyway, I will ask for more comments from the 
operators.

For your coclusion, I'm very confused. From where do you say that the draft 
admits that this is not needed? If we think what we want is not needed, why we 
submit this doc. If some words in the doc mislead you, I apologize and will 
polish them.

Thank you again for your review.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Joel Halpern
Date: 2018-04-13 22:44
To: rtg-...@ietf.org
CC: 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 i...@ietf.org; opsawg@ietf.org; 
gen-...@ietf.org
Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Reviewer: Joel Halpern
Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still
have serious problems with this work.

The primary problem is that this seems to violate the designed work
distribution in the IPFIX architecture.  The draft itself notes that the
correlation requested could be done in the collector.  Which is where
correlation is designed to be done.  Instead, it puts a significant new
processing load on the router that is delivering the IPFIX information.  For
example, if one delivers IPFIX from the router data plane, one either has to
modify the router architecture to include additional complex computed
information in the data plane architecture (a bad place to add complexity) or
one has to give up and move all the information through the control plane.  And
even the control plane likely has to add complexity to its RIB logic, as it has
to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the router
by the claim that the unusual usage of applying community tags for geographical
location of customers is a common practice.  It is a legal practice.  And I
presume it is done somewhere or the authors would not be asking for it.   But
it is not common.

In short, since even the draft admits that this is not needed, I recommend
against publishing this document as an RFC.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Thank you for that pointer.  It is informative.
I looked at a number of the entries (trying to pick larger ISPs as more 
likely to need more information.)
What i see is some ISPs doing what Randy Bush mentioned, marking 
regions.  I see a few ISPs that explicitly mark country (or in one case 
city).  I see some that mix several pieces of information including 
country in the same community, making it hard to perform what this I-D 
calls for (not impossible, just harder).  I do not see any indication of 
wide-spread consistency.


It appears that this is of use to a few ISPs.  I have never argued that 
no one wants this (the authors would not have written it if no one 
wanted it.)


From what I can tell reading this, the value requires significantly 
more precision than "region".


Also, one of the arguments for doing this in the router is that you can 
get more timely and precise correlation.  Except that for geolocation of 
address blocks, upstream correlation seems to be quite sufficiently 
stable and precise.  NLRI may come and go.  I fone has geo-information, 
it is unlikely to change.


Yours,
Joel


On 4/15/18 12:09 PM, heasley wrote:

Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang:

Why do you think this is unusual and not common?


Possibly, with due respect, because he is not an operator?  While ASes often
do so internally, not all reveal it externally or not ubiquitously.  Browse
https://onestep.net/communities/ to find the geo tag values of various ASes.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[heasley]

Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang:
> Why do you think this is unusual and not common? 

Possibly, with due respect, because he is not an operator?  While ASes often
do so internally, not all reveal it externally or not ubiquitously.  Browse
https://onestep.net/communities/ to find the geo tag values of various ASes.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Randy Bush]

hi joel,

> The secondary problem is that this additional work is justified for
> the router by the claim that the unusual usage of applying community
> tags for geographical location of customers is a common practice.  It
> is a legal practice.  And I presume it is done somewhere or the
> authors would not be asking for it.  But it is not common.

actually, it is used.  not in the "this prefix originted in new
hampshire," sense, but for global isps, to tag the routing region of
origin, e.g. se asia, europe, noam, ...

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Eric,


On 15.04.18 13:32, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-opsawg-mud-20: 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-opsawg-mud/
>
>
>
> --
> DISCUSS:
> --
>
> Re-posted due to pilot error.
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the
> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.

MUD is primarily intended to address the former, but provides some
benefit against the latter in some cases.  In particular, MUD is
intended to keep devices from getting infected in the first place.  As a
side-effect, if a device *is* broken into, it may be possible to either
prevent additional access, or otherwise detect the break-in based on a
change in profile.  I propose to state this more clearly in the
introduction, as follows:

NEW:

MUD primarily addresses threats to the device rather than the device as
a threat.  In some circumstances, however, MUD may offer some protection
in the latter case, depending on the MUD-URL is communicated, and how
devices and their communications are authenticated.

**
>
>
>
>
>
> IMPORTANT
>>  The certificate extension is described below.
>>
>>  The information returned by the MUD file server (a web server) is
>>  valid for the duration of the Thing's connection, or as specified in
>>  the description.  Thus if the Thing is disconnected, any associated
>>  configuration in the switch can be removed.  Similarly, from time to
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).

Yes, configuration is intended to be removed when a device disconnects
or a session terminates.  This would be considered normal garbage
collection.  But whether or not you can simply replace the firmware and
gain the same access will depend on how the MUD-URL is learned.  If it
is in a manufacturer certificate, for instance, that's not something an
attacker will easily replace.  If the assertion is coming via LLDP, or
DHCP, then one has to apply the mitigations discussed in the security
considerations section (and they are numerous).


>
>
>>https://example.com/lightbulbs/colour/v1
>>
>>  The MUD URL identifies a Thing with a specificity according to the
>>  manufacturer's wishes.  It could include a brand name, model number,
>>  or something more specific.  It also could provide a means to
>>  indicate what version the product is.
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
> doesn't seem like the MUD controller can infer any of those
> characteristics from the URL.

This is a bit of an artifact from some changes in earlier versions,
which did indeed have a schema.  I propose to replace that paragraph as
follows:

A manufacturer may construct a MUD URL in any way, so long as it makes
use of the "https" schema.

 
>
>>-in mudfile -binary -outform DER - \
>>-certfile intermediatecert -out mudfile.p7s
>>
>>  Note: A MUD file may need to be re-signed if the signature expires.
>>
>>   12.2.  Verifying a MUD file signature
> 

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear  wrote:

> Hi Eric,
>
> On 15.04.18 13:32, Eric Rescorla wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-opsawg-mud-20: 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-opsawg-mud/
>
>
>
> --
> DISCUSS:
> --
>
> Re-posted due to pilot error.
>
> Rich version of this review at:https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the
> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.
>
>
> MUD is primarily intended to address the former, but provides some benefit
> against the latter in some cases.  In particular, MUD is intended to keep
> devices from getting infected in the first place.  As a side-effect, if a
> device *is* broken into, it may be possible to either prevent additional
> access, or otherwise detect the break-in based on a change in profile.  I
> propose to state this more clearly in the introduction, as follows:
>
> NEW:
>
> MUD primarily addresses threats to the device rather than the device as a
> threat.  In some circumstances, however, MUD may offer some protection in
> the latter case, depending on the MUD-URL is communicated, and how devices
> and their communications are authenticated.
>

LGTM


>
>
> IMPORTANT
>
>  The certificate extension is described below.
>
>  The information returned by the MUD file server (a web server) is
>  valid for the duration of the Thing's connection, or as specified in
>  the description.  Thus if the Thing is disconnected, any associated
>  configuration in the switch can be removed.  Similarly, from time to
>
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).
>
>
> Yes, configuration is intended to be removed when a device disconnects or
> a session terminates.  This would be considered normal garbage collection..
> But whether or not you can simply replace the firmware and gain the same
> access will depend on how the MUD-URL is learned.  If it is in a
> manufacturer certificate, for instance, that's not something an attacker
> will easily replace.  If the assertion is coming via LLDP, or DHCP, then
> one has to apply the mitigations discussed in the security considerations
> section (and they are numerous).
>

I'm not following you here. Say it's in a manufacturer certificate, what
stops me from getting my own certificate for Attacker LLC and then serving
a wide open policy? The mitigations don't really seem to do much to
counteract this.


>  The MUD URL identifies a Thing with a specificity according to the
>  manufacturer's wishes.  It could include a brand name, model number,
>  or something more specific.  It also could provide a means to
>  indicate what version the product is.
>
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
> doesn't seem like the MUD controller can infer any of those
> characteristics from the URL.
>
>
> This is a bit of an artifact from some changes in earlier versions, which
> did indeed have a schema.  I propose to replace that paragraph as follows:
>
> A manufacturer may construct a MUD URL in any way, so long 

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Randy Bush]

> I fone has geo-information, it is unlikely to change.

i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever.  it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.

when you find yourself in a hole, first thing is to stop digging.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Randy, I did suggest that one would update the offline data.
My point was that the draft claims taht extreme timliness is needed. 
For IP block geolocation, timeliness on the order of a day (much shorter 
than the several days before the IETF when the IETF block gets turned on 
somewhere.)


Thus, again, you are not making a case for why the existing techniques 
which are easier to implement and deploy are not sufficie3nt for the 
problem.


Yours,
Joel

On 4/15/18 6:28 PM, Randy Bush wrote:

I fone has geo-information, it is unlikely to change.


i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever.  it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.

when you find yourself in a hole, first thing is to stop digging.

___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

randy, noting that the IETF has trouble with the geo-tagging of its 
addresses does not seem to have ANYTHING to do with demonstrating how 
widely used the geo-communities are.


If you want to make that case, make it.  But don't bring up red herrings.

As you note, it is up to the WG, not to me, what to ask for regarding 
this draft.  And it is up to the ADs to judge whether this is a good 
thing to standardize.


Yours,
Joel

On 4/15/18 6:53 PM, Randy Bush wrote:

Thus, again, you are not making a case for why the existing techniques
which are easier to implement and deploy are not sufficie3nt for the
problem.


correct.  i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
granularities.  you are not required to agree.

and you can argue the rest with someone else.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Randy Bush]

> Thus, again, you are not making a case for why the existing techniques
> which are easier to implement and deploy are not sufficie3nt for the
> problem.

correct.  i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
granularities.  you are not required to agree.

and you can argue the rest with someone else.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Aijun Wang]

Hi, Joel:

Can we consider this draft from other viewpoints? If the router can report
and correlate the traffic with its associated community, the usage of the
community to differentiate the customer, the service category that be
accessed and the geographical region etc. will be flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

 

 

Best Regards.

 

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

 

From: Joel Halpern  

Date: 2018-04-13 22:44

To: rtg-...@ietf.org

CC: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
opsawg@ietf.org; gen-...@ietf.org

Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

 

This is both a gen-art re-review and a routing directorate requested review.

 

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

 

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add complexity)
or

one has to give up and move all the information through the control plane.
And

even the control plane likely has to add complexity to its RIB logic, as it
has

to move additional information from BGP to the common structures.

 

The secondary problem is that this additional work is justified for the
router

by the claim that the unusual usage of applying community tags for
geographical

location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for it.
But

it is not common.

 

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.

 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

There seem to be two separate issues.

The first issue is what information from BGP would one like to correlate 
with the traffic flows.  I understand that there is useful information. 
The motivation given in the draft seems to apply to more cases than I 
thought, but still it is of limited applicability.


More importantly is the question of whether the proposed method is the 
right way to get the information.  As the draft acknowledges, there are 
other ways to get the information.  Ways that do not need new router 
software much less modifications of the fast path.
There is an argument in the draft about timeliness.  At least for the 
use case document in the draft, that argument does not hold water.


Yours,
Joel

On 4/15/18 10:45 PM, Aijun Wang wrote:

Hi, Joel:

Can we consider this draft from other viewpoints? If the router can
report and correlate the traffic with its associated community, the
usage of the community to differentiate the customer, the service
category that be accessed and the geographical region etc. will be
flourished.

And currently, China Telecom has some internal usage regulation for
community to differentiate some important customers and the related
services.

Best Regards.

Aijun Wang

Network R and Operation Support Department

China Telecom Corporation Limited Beijing Research
Institute,Beijing, China.

*From:*Joel Halpern 

*Date:* 2018-04-13 22:44

*To:*rtg-...@ietf.org 

*CC:*draft-ietf-opsawg-ipfix-bgp-community@ietf.org 
; 
i...@ietf.org ; opsawg@ietf.org 
; gen-...@ietf.org 


*Subject:* Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern

Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still

have serious problems with this work.

The primary problem is that this seems to violate the designed work

distribution in the IPFIX architecture.  The draft itself notes that the

correlation requested could be done in the collector.  Which is where

correlation is designed to be done.  Instead, it puts a significant new

processing load on the router that is delivering the IPFIX information.  For

example, if one delivers IPFIX from the router data plane, one either has to

modify the router architecture to include additional complex computed

information in the data plane architecture (a bad place to add 
complexity) or


one has to give up and move all the information through the control 
plane.  And


even the control plane likely has to add complexity to its RIB logic, as 
it has


to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the 
router


by the claim that the unusual usage of applying community tags for 
geographical


location of customers is a common practice.  It is a legal practice.  And I

presume it is done somewhere or the authors would not be asking for 
it.   But


it is not common.

In short, since even the draft admits that this is not needed, I recommend

against publishing this document as an RFC.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Randy Bush]

> As far as I can see, this document proposed a new aggregation
> parameter for IPFIX. So that the operators can get the traffic
> statistic from a new dimension.
>
> Because "Flow information based on IP address or IP prefix may provide
> much too fine granularity for a large network. On the contrary, flow
> information based on AS number may be too coarse."
>
> It sounds reasonable.

iff i can select which community's or communities' values form the
sampling bucket(s), this seems reasonable.  if i am community
transparent, i probably don't want a bucket for each community on my
inbound set.

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [RTG-DIR] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Joel M. Halpern]

Thank you Jimmy.
While I disagree, I think this states the case clearly enough for it to 
be up to the working group and relevant ADs.


Yours,
Joel

On 4/15/18 11:40 PM, Dongjie (Jimmy) wrote:

Hi Joel,

Thanks a lot for your review comments.

Regarding your first problem, I don't think this draft introduces "significant new 
processing load on the router", as similar processing has already been done for the 
BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the 
BGP-community based traffic collection is done by BGP lookup and correlating the BGP 
community with the flow data to be exported. Whether it is done in data plane or control 
plane is implementation specific and IMO does not belong to a IETF document.

As for your second problem, as many operators have pointed out, it is a common 
case to use BGP communities to represent geo locations at various 
granularities. So we need to provide them the tools to meet their requirements. 
Standardizing the IEs for BGP community is a good start.

Best regards,
Jie


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com]
Sent: Friday, April 13, 2018 10:44 PM
To: rtg-...@ietf.org
Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
opsawg@ietf.org; gen-...@ietf.org
Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Reviewer: Joel Halpern
Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still
have serious problems with this work.

The primary problem is that this seems to violate the designed work
distribution in the IPFIX architecture.  The draft itself notes that the
correlation requested could be done in the collector.  Which is where
correlation is designed to be done.  Instead, it puts a significant new
processing load on the router that is delivering the IPFIX information.  For
example, if one delivers IPFIX from the router data plane, one either has to
modify the router architecture to include additional complex computed
information in the data plane architecture (a bad place to add complexity) or
one has to give up and move all the information through the control plane.
And even the control plane likely has to add complexity to its RIB logic, as it 
has
to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the router 
by
the claim that the unusual usage of applying community tags for geographical
location of customers is a common practice.  It is a legal practice.  And I
presume it is done somewhere or the authors would not be asking for it.   But
it is not common.

In short, since even the draft admits that this is not needed, I recommend
against publishing this document as an RFC.




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Dongjie (Jimmy)]

Hi Joel, 

Thanks a lot for your review comments. 

Regarding your first problem, I don't think this draft introduces "significant 
new processing load on the router", as similar processing has already been done 
for the BGP AS number and BGP-nexthop based traffic collection. As described in 
the draft, the BGP-community based traffic collection is done by BGP lookup and 
correlating the BGP community with the flow data to be exported. Whether it is 
done in data plane or control plane is implementation specific and IMO does not 
belong to a IETF document. 

As for your second problem, as many operators have pointed out, it is a common 
case to use BGP communities to represent geo locations at various 
granularities. So we need to provide them the tools to meet their requirements. 
Standardizing the IEs for BGP community is a good start.

Best regards,
Jie

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Friday, April 13, 2018 10:44 PM
> To: rtg-...@ietf.org
> Cc: draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org;
> opsawg@ietf.org; gen-...@ietf.org
> Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
> 
> Reviewer: Joel Halpern
> Review result: Not Ready
> 
> This is both a gen-art re-review and a routing directorate requested review.
> 
> The revisions from draft-04 to -06 show some improvement.  However, I still
> have serious problems with this work.
> 
> The primary problem is that this seems to violate the designed work
> distribution in the IPFIX architecture.  The draft itself notes that the
> correlation requested could be done in the collector.  Which is where
> correlation is designed to be done.  Instead, it puts a significant new
> processing load on the router that is delivering the IPFIX information.  For
> example, if one delivers IPFIX from the router data plane, one either has to
> modify the router architecture to include additional complex computed
> information in the data plane architecture (a bad place to add complexity) or
> one has to give up and move all the information through the control plane.
> And even the control plane likely has to add complexity to its RIB logic, as 
> it has
> to move additional information from BGP to the common structures.
> 
> The secondary problem is that this additional work is justified for the 
> router by
> the claim that the unusual usage of applying community tags for geographical
> location of customers is a common practice.  It is a legal practice.  And I
> presume it is done somewhere or the authors would not be asking for it.   But
> it is not common.
> 
> In short, since even the draft admits that this is not needed, I recommend
> against publishing this document as an RFC.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Tianran Zhou]

Hi Joel,

> From what I can tell reading this, the value requires significantly more
> precision than "region".

As far as I can see, this document proposed a new aggregation parameter for 
IPFIX. So that the operators can get the traffic statistic from a new dimension.
Because "Flow information based on IP address or IP prefix may provide much too 
fine granularity for a large network. On the contrary, flow information based 
on AS number may be too coarse."
It sounds reasonable.


Tianran

> -Original Message-
> From: Joel M. Halpern [mailto:j...@stevecrocker.com]
> Sent: Monday, April 16, 2018 12:33 AM
> To: heasley ; li zhenqiang 
> Cc: rtg-...@ietf.org; gen-...@ietf.org;
> draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org; opsawg
> 
> Subject: Re: Rtgdir early review of
> draft-ietf-opsawg-ipfix-bgp-community-06
> 
> Thank you for that pointer.  It is informative.
> I looked at a number of the entries (trying to pick larger ISPs as more likely
> to need more information.) What i see is some ISPs doing what Randy Bush
> mentioned, marking regions.  I see a few ISPs that explicitly mark country
> (or in one case city).  I see some that mix several pieces of information
> including country in the same community, making it hard to perform what this
> I-D calls for (not impossible, just harder).  I do not see any indication
> of wide-spread consistency.
> 
> It appears that this is of use to a few ISPs.  I have never argued that no
> one wants this (the authors would not have written it if no one wanted it.)
> 
>  From what I can tell reading this, the value requires significantly more
> precision than "region".
> 
> Also, one of the arguments for doing this in the router is that you can get
> more timely and precise correlation.  Except that for geolocation of address
> blocks, upstream correlation seems to be quite sufficiently stable and
> precise.  NLRI may come and go.  I fone has geo-information, it is unlikely
> to change.
> 
> Yours,
> Joel
> 
> 
> On 4/15/18 12:09 PM, heasley wrote:
> > Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang:
> >> Why do you think this is unusual and not common?
> >
> > Possibly, with due respect, because he is not an operator?  While ASes
> > often do so internally, not all reveal it externally or not
> > ubiquitously.  Browse https://onestep.net/communities/ to find the geo
> tag values of various ASes.
> >
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-opsawg-mud-20: 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-opsawg-mud/



--
COMMENT:
--

Substantive:

§1.6, 2nd paragraph: Why is the SHOULD not a MUST?

§1.8, 4th paragraph: "The web server is typically run by or on behalf of the
manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to
operational considerations, especially around Thing lifecycle and ownership.

Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a reader
of the abstract in isolation from the rest of the document. (Abstracts should
be able to stand alone.)

§1.1 : first paragraph: The idea that a Thing might have highly restricted
communication patterns seems core to the document. It would be helpful to
mention that earlier in §1.

§1.3, definition of "Manufacturer": The definition says that "Manufacturer" may
not necessarily be the entity that constructed the Thing. But that's the plain
English meaning of the word "manufacturer". If you don't want it to mean that,
please consider choosing a different term. ( for example, "authority")

§1.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities"
should have been "requirements"?

§1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and
otherwise difficult to parse.

§1.9, list item 7:  are we talking about transient disconnect or permanent
removal?

§2: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

§3.8, 2nd sentence: Consider reformulating this as a construction of MUST.

§4: The idea of a "default" in bullet 2 seems in tension with the idea of
"Anything not explicitly permitted is forbidden" in bullet 1.

§14: Please define the concept of "east-west infection".


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg