Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Michael Richardson]

{my appologies for still getting captive-portal vs captive-portals@ wrong}

John Romkey  wrote:
>> Eliot Lear  wrote:
>>
 to retrieve a JSON object telling it that it is captive. At which 
point, it
 can flash a LED, or attempt a firmware upgrade, or maybe just reboot 
if a
 timer goes off.  (%)
>>
>>> You are suggesting that a device self-remediate.  Some devices may be
>>> able to eventually do that, but I have my doubts.  Were I a hacker, I
>>> would have the device pretend to do just that.  And so this ties
>>> somewhat to RATS.  I think a MUD extension might be able to help in as
>>> much as one could imagine a “remediation” recommendation.
>>
>> Yes, so a full attack on the IoT device would do what you describe.
>> A partial attack might miss messing this.  A reboot might clear out the
>> malware, or might mitigate it enough (such as going to boot firmware) 
that
>> would permit new firmware to be loaded.
>>
>> Yes, getting completely out of the quarantine would require either
>> attestation or human intervention.  But, if the device now has good 
firmware,
>> it would be able to send the "please unquarantine me" signal.

> I believe strongly that the only safe thing you can do with a device
> that’s been in any way compromised is completely isolate it.It
> shouldn’t be able to send an “unquarantine” signal. You shouldn’t even
> try to talk to it.

That's a reasonable view.
The question is: what next?
   draft-richardson-shg-un-quarantine-00
tries to discuss this.

> Let the firewall which is implementing MUD notify the user about the
> problem. Let the device’s app or cloud services notify the user that
> the device is offline. Possibly in a later evolution of MUD the
> firewall might have a way to notify the device’s cloud service, but I
> wouldn’t hamstring the initial version of MUD with an attempt to do
> that.

I fully expect any notifications out should be done by the firewall.
There are two issues I'm trying to address:
  1) there will be false positives from use of MUD.  Manufacturers will
 screw up, DNS mappings will be updated out of sync with firmware, etc.
 If it is too painful to diagnose and fix, then MUD will get disabled by
 operators (ISPs, who will get the call), or by end users.

  2) not every user of a device will get the notifications.
 So devices with displays (think: thermostats, refridgerators, SIP phones,
 TV sets, etc.) whether they have real malware on them, or false
 positives should be able to indicate that they are offline.
 This matters a lot if you are trying to dial 911 on a broken phone,
 and you aren't the person with the app that gets the notifications
 from the firewall.

Putting them behind the captive-portal API when quarantined lets them get
exactly the kind of information they want.  It also helps them when they
turned on where there really is a captive-portal.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] putting quarantined IoT devices behind a captive portal

[Michael Richardson]

Montgomery, Douglas (Fed)  wrote:
> Most of the devices I think of as actual IoT devices have no direct
> UI/shell.  Your only interaction with them after initial
> “install/configure” is through their cloud web service interface.

That's true for many devices, but not all.
Even light bulbs have output interfaces :-)

> Having said that I think your model is fine.

Good.

> I would suggest detecting device reboot would be one signal to clear
> quarantine state.  Since MUD “misbehavior” is mostly instantaneously
> detectable (1 packet), I am not that concerned that the device might
> reboot for others reasons and still be infected.

Device reboot probably needs an attestation to be believed.

> One might keep a counter and a time stamp of quarantine clears and if
> you a device had N MUD violations after quarantine clears in X time,
> lock it down in quarantine or completely take it off line.

Reasonable, but in the space of quality of implementation, I think.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Michael Richardson]

Juergen Schoenwaelder  wrote:
> would an ICMP "administratively prohibited" not be a sufficient
> signal? Sure, things can be made much more complex, but I doubt that
> devices will try to actively investigate why they can't communicate

Probably good enough.  Some wanted a more specific signal.

It's intended to just be a signal to go ask the captive portal API
if the device is captive.

> (and implement additional protocols for this) if all they can do at
> the end is to change the color of an led or simply shut-off (i.e.,
> stop assuming its a temporary network issue and reduce/stop probing
> effort).

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Michael Richardson]

Eliot Lear  wrote:
> It’s the following part that I’m thinking about:




>> to retrieve a JSON object telling it that it is captive. At which point, 
it
>> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
>> timer goes off.  (%)

> You are suggesting that a device self-remediate.  Some devices may be
> able to eventually do that, but I have my doubts.  Were I a hacker, I
> would have the device pretend to do just that.  And so this ties
> somewhat to RATS.  I think a MUD extension might be able to help in as
> much as one could imagine a “remediation” recommendation.

Yes, so a full attack on the IoT device would do what you describe.
A partial attack might miss messing this.  A reboot might clear out the
malware, or might mitigate it enough (such as going to boot firmware) that
would permit new firmware to be loaded.

Yes, getting completely out of the quarantine would require either
attestation or human intervention.  But, if the device now has good firmware,
it would be able to send the "please unquarantine me" signal.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] putting quarantined IoT devices behind a captive portal

[M. Ranganathan]

On Tue, Jul 9, 2019 at 4:13 PM M. Ranganathan  wrote:

> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>


Wrong reference, I meant


https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/

(sorry for extra email load).

Assumes that the "quarantined device" can access a subset of the ACE's
> allowed to the "unquarantined" device.
> However, I can think of a scenario where this does not have to be the
> case. I'd propose to generalize this.
>
> i.e. There are two sets of ACL's - one for normal operation and one for
> quarantined access. (i.e. quarantine access is not necessarily a subset of
> regular access).
>
> Use case:
>
> Under normal circumstances, the device does not need SSH access (port 22
> is not open). However, if the device is misbehaving some external agent (or
> human maybe) logs in and investigates the issue.  The fix could involve
> copying new firmware.
>
> Does this make sense?
>
> Another thing that is missing currently is how to "clear" the quarantine
> state at the enforcement point. This would need an API defintion of we want
> to make that portable.
>
> Regards,
>
> Ranga
>
>
> On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson 
> wrote:
>
>>
>> Eliot Lear  wrote:
>> > I’m not quite certain how it would work.  Can you show a flow that
>> will
>> > work for an IoT device (e.g., headless and no display)?
>>
>> Device gets quarantined, and the MUD-controller moves it into an isolated
>> "VLAN".  I put air/scare quotes around VLAN, because it's a "MAC-address
>> VLAN", not an 802.1Q thing.  It's really just a layer-2 ACL.
>>
>> {We have no way to force the mishaving device into tagging it's packets,
>> nor
>> can we force it onto some other ESSID. We can't do a "port-based" VLAN,
>> because wifi has no ports, and we don't really know how many unmanaged
>> switches might be on the port anyway.
>> One might map this onto a IEEE 802.1Q VLAN across a backbone}
>>
>> Instead of just dropping all traffic for a device in this category,
>> all traffic (other than excepted traffic if you implement
>>
>> https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/
>> )
>> would go into a captive portal system.
>>
>> Such a system would, according to
>> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
>> receive a message when it initiates connections which are not allowed.
>> (While the capport WG contemplated an ICMP unreachable message with a
>> URI in it at one point, that is not the current design)
>>
>> Actually, I have no idea from reviewing the documentation what the
>> appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
>>
>> Once the IoT device gets such a message, it can use the API
>> described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>> to retrieve a JSON object telling it that it is captive. At which point,
>> it
>> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
>> timer goes off.  (%)
>>
>> This requires that the IoT device get the captive portal API end point,
>> which
>> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can
>> deliver
>> via DHCPv4/v6 or RA.
>>
>>
>> >> On 9 Jul 2019, at 16:41, Michael Richardson > >
>> >> wrote:
>> >>
>> >> Signed PGP part
>> >>
>> >> Between editing drafts yesterday, I got to thinking about
>> CAPPORT.  I
>> >> have been working on what to do when an IoT device violates it's
>> MUD
>> >> profile.  There are a bunch of issues around this.
>> >>
>> >> Yesterday, it occured to me that when such a device is quarantined
>> (I
>> >> really think it should be "quaranteed", but that's not a word) that
>> >> the capport controls and APIs should be available to the device to
>> >> learn what went on.
>> >>
>> >> This is not new, I think that this as been the approach of most
>> >> enterprise NEA systems upon encountering "infection".  This has, I
>> >> assume, involved forced HTTP proxies to inform human.  But, if we
>> have
>> >> APIs, we can inform device as well.
>> >>
>> >> Is this on anyone's radar?
>> >>
>> >> --
>> >> Michael Richardson , Sandelman Software
>> Works
>> >> -= IPv6 IoT consulting =-
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
>> --
>> Michael Richardson , Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>> --
>> Mud mailing list
>> m...@ietf.org
>> https://www.ietf.org/mailman/listinfo/mud
>>
>
>
> --
> M. Ranganathan
>
>

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

Re: [OPSAWG] [Mud] putting quarantined IoT devices behind a captive portal

[M. Ranganathan]

The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
Assumes that the "quarantined device" can access a subset of the ACE's
allowed to the "unquarantined" device.
However, I can think of a scenario where this does not have to be the case.
I'd propose to generalize this.

i.e. There are two sets of ACL's - one for normal operation and one for
quarantined access. (i.e. quarantine access is not necessarily a subset of
regular access).

Use case:

Under normal circumstances, the device does not need SSH access (port 22 is
not open). However, if the device is misbehaving some external agent (or
human maybe) logs in and investigates the issue.  The fix could involve
copying new firmware.

Does this make sense?

Another thing that is missing currently is how to "clear" the quarantine
state at the enforcement point. This would need an API defintion of we want
to make that portable.

Regards,

Ranga


On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson 
wrote:

>
> Eliot Lear  wrote:
> > I’m not quite certain how it would work.  Can you show a flow that
> will
> > work for an IoT device (e.g., headless and no display)?
>
> Device gets quarantined, and the MUD-controller moves it into an isolated
> "VLAN".  I put air/scare quotes around VLAN, because it's a "MAC-address
> VLAN", not an 802.1Q thing.  It's really just a layer-2 ACL.
>
> {We have no way to force the mishaving device into tagging it's packets,
> nor
> can we force it onto some other ESSID. We can't do a "port-based" VLAN,
> because wifi has no ports, and we don't really know how many unmanaged
> switches might be on the port anyway.
> One might map this onto a IEEE 802.1Q VLAN across a backbone}
>
> Instead of just dropping all traffic for a device in this category,
> all traffic (other than excepted traffic if you implement
>
> https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/
> )
> would go into a captive portal system.
>
> Such a system would, according to
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
> receive a message when it initiates connections which are not allowed.
> (While the capport WG contemplated an ICMP unreachable message with a
> URI in it at one point, that is not the current design)
>
> Actually, I have no idea from reviewing the documentation what the
> appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
>
> Once the IoT device gets such a message, it can use the API
> described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> to retrieve a JSON object telling it that it is captive. At which point, it
> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
> timer goes off.  (%)
>
> This requires that the IoT device get the captive portal API end point,
> which
> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can
> deliver
> via DHCPv4/v6 or RA.
>
>
> >> On 9 Jul 2019, at 16:41, Michael Richardson 
> >> wrote:
> >>
> >> Signed PGP part
> >>
> >> Between editing drafts yesterday, I got to thinking about CAPPORT.
> I
> >> have been working on what to do when an IoT device violates it's MUD
> >> profile.  There are a bunch of issues around this.
> >>
> >> Yesterday, it occured to me that when such a device is quarantined
> (I
> >> really think it should be "quaranteed", but that's not a word) that
> >> the capport controls and APIs should be available to the device to
> >> learn what went on.
> >>
> >> This is not new, I think that this as been the approach of most
> >> enterprise NEA systems upon encountering "infection".  This has, I
> >> assume, involved forced HTTP proxies to inform human.  But, if we
> have
> >> APIs, we can inform device as well.
> >>
> >> Is this on anyone's radar?
> >>
> >> --
> >> Michael Richardson , Sandelman Software
> Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >>
> >>
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --
> Mud mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mud
>


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

Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Juergen Schoenwaelder]

Michael,

would an ICMP "administratively prohibited" not be a sufficient
signal? Sure, things can be made much more complex, but I doubt that
devices will try to actively investigate why they can't communicate
(and implement additional protocols for this) if all they can do at
the end is to change the color of an led or simply shut-off (i.e.,
stop assuming its a temporary network issue and reduce/stop probing
effort).

/js

On Tue, Jul 09, 2019 at 02:38:58PM -0400, Michael Richardson wrote:
> 
> Eliot Lear  wrote:
> > I’m not quite certain how it would work.  Can you show a flow that will
> > work for an IoT device (e.g., headless and no display)?
> 
> Device gets quarantined, and the MUD-controller moves it into an isolated
> "VLAN".  I put air/scare quotes around VLAN, because it's a "MAC-address
> VLAN", not an 802.1Q thing.  It's really just a layer-2 ACL.
> 
> {We have no way to force the mishaving device into tagging it's packets, nor
> can we force it onto some other ESSID. We can't do a "port-based" VLAN,
> because wifi has no ports, and we don't really know how many unmanaged
> switches might be on the port anyway.
> One might map this onto a IEEE 802.1Q VLAN across a backbone}
> 
> Instead of just dropping all traffic for a device in this category,
> all traffic (other than excepted traffic if you implement
> https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/)
> would go into a captive portal system.
> 
> Such a system would, according to
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
> receive a message when it initiates connections which are not allowed.
> (While the capport WG contemplated an ICMP unreachable message with a
> URI in it at one point, that is not the current design)
> 
> Actually, I have no idea from reviewing the documentation what the
> appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
> 
> Once the IoT device gets such a message, it can use the API
> described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> to retrieve a JSON object telling it that it is captive. At which point, it
> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
> timer goes off.  (%)
> 
> This requires that the IoT device get the captive portal API end point, which
> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver
> via DHCPv4/v6 or RA.
> 
> 
> >> On 9 Jul 2019, at 16:41, Michael Richardson 
> >> wrote:
> >>
> >> Signed PGP part
> >>
> >> Between editing drafts yesterday, I got to thinking about CAPPORT.  I
> >> have been working on what to do when an IoT device violates it's MUD
> >> profile.  There are a bunch of issues around this.
> >>
> >> Yesterday, it occured to me that when such a device is quarantined (I
> >> really think it should be "quaranteed", but that's not a word) that
> >> the capport controls and APIs should be available to the device to
> >> learn what went on.
> >>
> >> This is not new, I think that this as been the approach of most
> >> enterprise NEA systems upon encountering "infection".  This has, I
> >> assume, involved forced HTTP proxies to inform human.  But, if we have
> >> APIs, we can inform device as well.
> >>
> >> Is this on anyone's radar?
> >>
> >> --
> >> Michael Richardson , Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >>
> >>
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



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


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Eliot Lear]

It’s the following part that I’m thinking about:

> On 9 Jul 2019, at 20:38, Michael Richardson  wrote:
> 
> Such a system would, according to
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
> receive a message when it initiates connections which are not allowed.
> (While the capport WG contemplated an ICMP unreachable message with a
> URI in it at one point, that is not the current design)
> 
> Actually, I have no idea from reviewing the documentation what the
> appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT?
> 
> Once the IoT device gets such a message, it can use the API
> described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> to retrieve a JSON object telling it that it is captive. At which point, it
> can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a
> timer goes off.  (%)
> 


You are suggesting that a device self-remediate.  Some devices may be able to 
eventually do that, but I have my doubts.  Were I a hacker, I would have the 
device pretend to do just that.  And so this ties somewhat to RATS.  I think a 
MUD extension might be able to help in as much as one could imagine a 
“remediation” recommendation.

Eliot

> This requires that the IoT device get the captive portal API end point, which
> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver
> via DHCPv4/v6 or RA.
> 
> 
>>> On 9 Jul 2019, at 16:41, Michael Richardson 
>>> wrote:
>>> 
>>> Signed PGP part
>>> 
>>> Between editing drafts yesterday, I got to thinking about CAPPORT.  I
>>> have been working on what to do when an IoT device violates it's MUD
>>> profile.  There are a bunch of issues around this.
>>> 
>>> Yesterday, it occured to me that when such a device is quarantined (I
>>> really think it should be "quaranteed", but that's not a word) that
>>> the capport controls and APIs should be available to the device to
>>> learn what went on.
>>> 
>>> This is not new, I think that this as been the approach of most
>>> enterprise NEA systems upon encountering "infection".  This has, I
>>> assume, involved forced HTTP proxies to inform human.  But, if we have
>>> APIs, we can inform device as well.
>>> 
>>> Is this on anyone's radar?
>>> 
>>> --
>>> Michael Richardson , Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[john heasley]

> This document was presented in Prague. The authors have addressed all the 
> comments and believe it's ready for further working group discussion.
> 
> https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02
> 
> This email starts a two weeks poll for adoption.
> 
> If you support adopting this document please say so, and please give an 
> indication of why you think it is important. Also please say if you will be 
> willing to review and help the draft.

I support adoption.  As with RADIUS, a model is necessary to configure
Tacacs+ servers on Tacacs+ client devices.

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

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Joe Clarke (jclarke)]

On Jul 9, 2019, at 05:35, Eliot Lear mailto:l...@cisco.com>> 
wrote:



On 9 Jul 2019, at 08:59, Wubo (lana) 
mailto:lana.w...@huawei.com>> wrote:

Thank Eliot for pointing out these questions. I share a similar view with Qin, 
and I suggest to make the following changes in the next version:

1. draft-ietf-opsawg-tacacs will be changed as a normative reference according 
to RFC3967.

Several points: please take into account that RFC 8067 updates RFC 3967.  What 
this means is that you should probably have a brief chat with the chairs and 
Ignas on this point to see what he wants.  It may also be worth a little bit of 
discussion time.

Agreed on your points here.  I do think this should be a standards track 
document, and I think a downref would be acceptable in this case.  But this is 
worth addressing as an issue for your draft in your slot.



2. For the second point, I think your concern may be whether the TACACS + YANG 
model is flexible enough to accommodate the TACACS advanced features.

I think the augmentation is exactly what you want to do for this sort of thing.

This was also my thinking.  If/when a T+/TLS draft comes out and additional 
configuration is required, that could be an augmentation or even a bis to this 
model.  From a YANG versioning standpoint, we want models to evolve.

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

Re: [OPSAWG] putting quarantined IoT devices behind a captive portal

[Eliot Lear]

I’m not quite certain how it would work.  Can you show a flow that will work 
for an IoT device (e.g., headless and no display)?

Eliot

> On 9 Jul 2019, at 16:41, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Between editing drafts yesterday, I got to thinking about CAPPORT.
> I have been working on what to do when an IoT device violates it's MUD
> profile.  There are a bunch of issues around this.
> 
> Yesterday, it occured to me that when such a device is quarantined
> (I really think it should be "quaranteed", but that's not a word)
> that the capport controls and APIs should be available to the device to
> learn what went on.
> 
> This is not new, I think that this as been the approach of most enterprise
> NEA systems upon encountering "infection".  This has, I assume, involved
> forced HTTP proxies to inform human.  But, if we have APIs, we can inform
> device as well.
> 
> Is this on anyone's radar?
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] putting quarantined IoT devices behind a captive portal

[Michael Richardson]

Between editing drafts yesterday, I got to thinking about CAPPORT.
I have been working on what to do when an IoT device violates it's MUD
profile.  There are a bunch of issues around this.

Yesterday, it occured to me that when such a device is quarantined
(I really think it should be "quaranteed", but that's not a word)
that the capport controls and APIs should be available to the device to
learn what went on.

This is not new, I think that this as been the approach of most enterprise
NEA systems upon encountering "infection".  This has, I assume, involved
forced HTTP proxies to inform human.  But, if we have APIs, we can inform
device as well.

Is this on anyone's radar?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Fwd: New Version Notification for draft-reddy-opswg-mud-tls-00.txt

[tirumal reddy]

Hi Qin,

Please see inline

On Tue, 9 Jul 2019 at 08:30, Qin Wu  wrote:

> Interesting work, three questions:
>
> 1.   Can the IoT device (D)TLS profile be disclosed to malicious agent or 
> IoT device? If not, how do you prevent these sensitive information leaking?
>
> It is not sensitive information, on-path network devices can inspect or
monitor the TLS handshake without acting as a TLS proxy. In TLS
1.3, ClientHello message is not encrypted and few parameters in the
ServerHello message are still visible (such as the chosen cipher).


> 2.   Do you frequently update DTLS profile disclosed to IoT device to 
> prevent malicious agent from snooping?
>
> No, Malware frequently uses its own libraries (SSL config) for its
activities, and malware developers will have to develop malicious agents
per IoT device type, manufacturer and model (which will be several
thousands and practically not possible).

> 3.   How does enterprise firewal use DTLS profile to detect malicious 
> flow or legitimate flow?
>
> If (D)TLS session from the IoT device violates MUD (D)TLS profile,
firewall detects the flow is malicious and blocks it. As you may know,
Enterprise firewalls inspect TLS handshake and are capable of acting as a
(D)TLS proxy (please see
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-05).

Cheers,
-Tiru

-Qin
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *tirumal reddy
> *发送时间:* 2019年7月8日 22:03
> *收件人:* opsawg@ietf.org; m...@ietf.org
> *主题:* [OPSAWG] Fwd: New Version Notification for
> draft-reddy-opswg-mud-tls-00.txt
>
>
>
> This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
> profile on IoT devices. This allows a firewall to notice abnormal DTLS or
> TLS usage, which has been a strong indicator of other software running on
> the endpoint, typically malware.
>
>
> Comments, suggestions, and questions are more than welcome.
>
> Cheers,
> -Tiru
>
>
>
> -- Forwarded message -
> From: 
> Date: Mon, 8 Jul 2019 at 19:18
> Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
> To: Tirumaleswar Reddy , Dan Wing 
>
>
>
>
> A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-opswg-mud-tls
> Revision:   00
> Title:  MUD (D)TLS profiles for IoT devices
> Document date:  2019-07-08
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
> Htmlized:   https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls
>
>
> Abstract:
>This memo extends Manufacturer Usage Description (MUD) to model DTLS
>and TLS usage.  This allows a network element to notice abnormal DTLS
>or TLS usage which has been strong indicator of other software
>running on the endpoint, typically malware.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] New Version Notification for draft-reddy-opswg-mud-tls-00.txt

[tirumal reddy]

Thanks Eliot, glad to present the draft.

-Tiru

On Mon, 8 Jul 2019 at 20:02, Eliot Lear  wrote:

> I think this is a pretty cool idea.  You should talk about it if you can
> make the side meeting, or otherwise if you can get time at opsawg.
>
> Eliot
>
> On 8 Jul 2019, at 16:03, tirumal reddy  wrote:
>
> This draft https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> discusses Manufacturer Usage Description (MUD) extension to model (D)TLS
> profile on IoT devices. This allows a firewall to notice abnormal DTLS or
> TLS usage, which has been a strong indicator of other software running on
> the endpoint, typically malware.
>
> Comments, suggestions, and questions are more than welcome.
>
> Cheers,
> -Tiru
>
> -- Forwarded message -
> From: 
> Date: Mon, 8 Jul 2019 at 19:18
> Subject: New Version Notification for draft-reddy-opswg-mud-tls-00.txt
> To: Tirumaleswar Reddy , Dan Wing 
>
>
>
> A new version of I-D, draft-reddy-opswg-mud-tls-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-opswg-mud-tls
> Revision:   00
> Title:  MUD (D)TLS profiles for IoT devices
> Document date:  2019-07-08
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/internet-drafts/draft-reddy-opswg-mud-tls-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opswg-mud-tls/
> Htmlized:   https://tools.ietf.org/html/draft-reddy-opswg-mud-tls-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-opswg-mud-tls
>
>
> Abstract:
>This memo extends Manufacturer Usage Description (MUD) to model DTLS
>and TLS usage.  This allows a network element to notice abnormal DTLS
>or TLS usage which has been strong indicator of other software
>running on the endpoint, typically malware.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> --
> Mud mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mud
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Eliot Lear]

> On 9 Jul 2019, at 08:59, Wubo (lana)  wrote:
> 
> Thank Eliot for pointing out these questions. I share a similar view with 
> Qin, and I suggest to make the following changes in the next version:
> 
> 1. draft-ietf-opsawg-tacacs will be changed as a normative reference 
> according to RFC3967.

Several points: please take into account that RFC 8067 updates RFC 3967.  What 
this means is that you should probably have a brief chat with the chairs and 
Ignas on this point to see what he wants.  It may also be worth a little bit of 
discussion time.

> 
> 2. For the second point, I think your concern may be whether the TACACS + 
> YANG model is flexible enough to accommodate the TACACS advanced features.

I think the augmentation is exactly what you want to do for this sort of thing.

> The current TACACS + YANG architecture is designed with per-server 
> configuration and statistics methods. Each server is configured with a TCP 
> port and a shared key.
> These nodes may change to use a "choice" statement. If the TACACS++ extends 
> to use TLS protocol, the transport extensions can be added as new "case" 
> statements.

From what I gather of the model, it merely talks about the state and 
configuration of the T+ connection itself.  I think this mitigates reasonably 
well in favor of a downref since that sort of state is not likely to change too 
much, and if it does, you can augment again.

Eliot

> 
> Thanks,
> Bo
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org ] 
> 代表 Qin Wu
> 发送时间: 2019年7月9日 11:20
> 收件人: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
> Eliot Lear mailto:l...@cisco.com>>
> 抄送: opsawg@ietf.org ; OpsAWG Chairs 
> mailto:opsawg-cha...@ietf.org>>
> 主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02
> 
> A few thoughts on Eliot’s two questions:
> 1.   Do we have YANG data model draft developed by IETF published as 
> informational RFC? I haven’t seen one.
> 2.   This model uses system management YANG data model defined in RFC7317 
> as base model and augment it with TACACS+ specifics, and RFC7317 is standard 
> track RFC.
> 3.   Downref is allowed in some circumstance, See RFC3967 section 2, 
> first two bullets.
> 4.   TACACS+ protocol has been moved for publication. Whether or not 
> TACACS++ comes later, TACACS+ will be basis for any advanced features. So 
> timing is perfect.
> 
> -Qin
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org ] 
> 代表 Tianran Zhou
> 发送时间: 2019年7月9日 10:35
> 收件人: Eliot Lear mailto:l...@cisco.com>>
> 抄送: opsawg@ietf.org ; OpsAWG Chairs 
> mailto:opsawg-cha...@ietf.org>>
> 主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02
> 
> Hi Eliot,
> 
> Thanks for your suggestions. Please see inline.
> 
> Tianran
> 
> From: Eliot Lear [mailto:l...@cisco.com ]
> Sent: Monday, July 08, 2019 8:13 PM
> To: Tianran Zhou mailto:zhoutian...@huawei.com>>
> Cc: opsawg@ietf.org ; OpsAWG Chairs 
> mailto:opsawg-cha...@ietf.org>>
> Subject: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02
> 
> Hi Tianran,
> 
> I have two concerns about this draft.  First is the intended status of this 
> document.  It currently calls out draft-ietf-opsawg-tacacs as an 
> informational reference.  I think the question here is really whether this 
> draft should also be informational.  As a practical matter you really do need 
> to have implemented the other draft for this one to be implemented.  And that 
> means that really it should be a normative reference.  But it would be a 
> downref.  To address this, I suggest just making this document an 
> informational draft, rather than targeting for standards, and make the 
> reference normative.
> 
> [Tianran] Yes, I have the same concern. You provided a good approach. On the 
> other hand, I think RFC3967 described this case.
> “2.  The Need for Downward References
> …
>o  A standards document may need to refer to a proprietary protocol,
>   and the IETF normally documents proprietary protocols using
>   informational RFCs.”
> 
> In addition, I have another question.  Is there interest or appetite for 
> creating a standardized and more version of T+?  If so, is the timing of a 
> standardized YANG model appropriate?
> 
> [Tianran] I would like to see how the WG would like to approach.
> 
> Eliot
> 
> 
> 
> On 7 Jul 2019, at 09:58, Tianran Zhou  > wrote:
> 
> Hi WG,
> 
> This document was presented in Prague. The authors have addressed all the 
> comments and believe it’s ready for further working group discussion.
> https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02 
> 
> 
> 
> This email starts a two weeks poll for adoption.
> If you support adopting this document please say so, and please give an 
> indication 

Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

[Wubo (lana)]

Thank Eliot for pointing out these questions. I share a similar view with Qin, 
and I suggest to make the following changes in the next version:

1. draft-ietf-opsawg-tacacs will be changed as a normative reference according 
to RFC3967.

2. For the second point, I think your concern may be whether the TACACS + YANG 
model is flexible enough to accommodate the TACACS advanced features.
The current TACACS + YANG architecture is designed with per-server 
configuration and statistics methods. Each server is configured with a TCP port 
and a shared key.
These nodes may change to use a "choice" statement. If the TACACS++ extends to 
use TLS protocol, the transport extensions can be added as new "case" 
statements.

Thanks,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Qin Wu
发送时间: 2019年7月9日 11:20
收件人: Tianran Zhou ; Eliot Lear 
抄送: opsawg@ietf.org; OpsAWG Chairs 
主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

A few thoughts on Eliot’s two questions:

1.   Do we have YANG data model draft developed by IETF published as 
informational RFC? I haven’t seen one.

2.   This model uses system management YANG data model defined in RFC7317 
as base model and augment it with TACACS+ specifics, and RFC7317 is standard 
track RFC.

3.   Downref is allowed in some circumstance, See RFC3967 section 2, first 
two bullets.

4.   TACACS+ protocol has been moved for publication. Whether or not 
TACACS++ comes later, TACACS+ will be basis for any advanced features. So 
timing is perfect.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2019年7月9日 10:35
收件人: Eliot Lear mailto:l...@cisco.com>>
抄送: opsawg@ietf.org; OpsAWG Chairs 
mailto:opsawg-cha...@ietf.org>>
主题: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

Hi Eliot,

Thanks for your suggestions. Please see inline.

Tianran

From: Eliot Lear [mailto:l...@cisco.com]
Sent: Monday, July 08, 2019 8:13 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>
Cc: opsawg@ietf.org; OpsAWG Chairs 
mailto:opsawg-cha...@ietf.org>>
Subject: Re: [OPSAWG] WG adoption poll for draft-zheng-opsawg-tacacs-yang-02

Hi Tianran,

I have two concerns about this draft.  First is the intended status of this 
document.  It currently calls out draft-ietf-opsawg-tacacs as an informational 
reference.  I think the question here is really whether this draft should also 
be informational.  As a practical matter you really do need to have implemented 
the other draft for this one to be implemented.  And that means that really it 
should be a normative reference.  But it would be a downref.  To address this, 
I suggest just making this document an informational draft, rather than 
targeting for standards, and make the reference normative.

[Tianran] Yes, I have the same concern. You provided a good approach. On the 
other hand, I think RFC3967 described this case.
“2.  The Need for Downward References
…
   o  A standards document may need to refer to a proprietary protocol,
  and the IETF normally documents proprietary protocols using
  informational RFCs.”

In addition, I have another question.  Is there interest or appetite for 
creating a standardized and more version of T+?  If so, is the timing of a 
standardized YANG model appropriate?

[Tianran] I would like to see how the WG would like to approach.

Eliot


On 7 Jul 2019, at 09:58, Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:

Hi WG,

This document was presented in Prague. The authors have addressed all the 
comments and believe it’s ready for further working group discussion.
https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-02


This email starts a two weeks poll for adoption.
If you support adopting this document please say so, and please give an 
indication of why you think it is important. Also please say if you will be 
willing to review and help the draft.
If you do not support adopting this document as a starting point for work on 
this topic, please say why..
This poll will run until 22nd July.

Regards,
Tianran & Joe

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

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