{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
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
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
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
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
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.
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
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
> 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
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.
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
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
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
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
> 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
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
16 matches
Mail list logo
