Subject: [PANRG] PANRG@IETF110: Call for presentations

From: Jen Linkova <[email-masked]>
Date: Wed, 6 Jan 2021 18:34:38 +1100

Hello,

The chairs have requested a 60 mins slot for PANRG at IETF110.
We are looking for the agenda items so if you'd like to present please
send your request to [email-masked].

P.S. As per https://www.ietf.org/how/meetings/110/ we expect the
session to be scheduled between 12:00 and 18:00 UTC, March 8-12.

-- 
SY, Jen Linkova aka Furry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 8 Jan 2021 16:18:08 -0600

Hi, Jen and Brian,

> send your request to [email-masked].

We've
got draft-irtf-panrg-questions-08  and draft-irtf-panrg-what-not-to-do-16
off at the IRSG now, and that's two out of three of our adopted RG
documents.

Is it worth talking about (I hope, on the mailing list) what we expect to
focus on, going forward?

I have some thoughts, but didn't want to ask to do a presentation if the
response to this presentation is known to be "that's not what we want to
do" now ...

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 18 Jan 2021 18:32:09 -0600

> response to this presentation is known to be "that's not what we want to

I'd invite other folk to chime in, of course, but I'd like to propose a
couple of topics for the IETF 110 PANRG session.

I've been thinking about the major issue of host trusting information
provided by "the network", and see if we can make some progress on that.

I'd like to talk for a bit, about what PANRG research goals might look
like. I brought this up some time ago, but got preempted with a new IETF
sponsor and new responsibilities, and have only now dug my way out into
daylight.

If the agenda fills up for our IETF 110 session, either or both of these
topics would be fine in a virtual interim meeting, of course.

Best,

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jan 2021 08:56:40 +0100

Hi all,

> On 19 Jan 2021, at 01:32, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 
> On Fri, Jan 8, 2021 at 4:18 PM Spencer Dawkins at IETF <[email-masked]> wrote:
> Hi, Jen and Brian, 
> 
> We've got draft-irtf-panrg-questions-08  and draft-irtf-panrg-what-not-to-do-16 off at the IRSG now, and that's two out of three of our adopted RG documents. 
> 
> Is it worth talking about (I hope, on the mailing list) what we expect to focus on, going forward?
> 
> I have some thoughts, but didn't want to ask to do a presentation if the response to this presentation is known to be "that's not what we want to do" now ... 
> 
> I'd invite other folk to chime in, of course, but I'd like to propose a couple of topics for the IETF 110 PANRG session. 
> 
> I've been thinking about the major issue of host trusting information provided by "the network", and see if we can make some progress on that. 

Unrelated to agenda planning (and sorry for derailing a bit), I just feel like tossing something here, to see how people will react. Probably I'm missing out on some recent work that's already along these lines... sorry in that case!  But - here it goes...

IMO, based on what I've seen, there's an unnecessary detachment between "application layer" (where we don't have these kinds of problems) and "the network" (where random devices talk to us, out of the blue).
That doesn't need to be the case. Just because devices are explicitly addressed (which must be the way to go if we should trust them), that doesn't force them to operate at the application layer alone. RFC 8803 is a fine example of that: a host talks to a proxy, says "please forward my data to the real destination, here's the address", and yet, the proxy is "allowed" to do TCP things (look at options and so forth). I can't understand why we couldn't authenticate (possibly on-path) devices in a similar way, even if their role would merely be to provide information?  E.g., if one of my ISP's boxes could supply my hosts with useful information, I'd happily add this box to my host's network configuration, using the details that my ISP has given me.

To me, that would seem like a feasible way to do this. I wonder why it's not already happening? Is there nothing useful that my ISP's boxes could tell my hosts? I doubt that.

Cheers,
Michael

> I'd like to talk for a bit, about what PANRG research goals might look like. I brought this up some time ago, but got preempted with a new IETF sponsor and new responsibilities, and have only now dug my way out into daylight. 
> 
> If the agenda fills up for our IETF 110 session, either or both of these topics would be fine in a virtual interim meeting, of course. 
> 
> Best,
> 
> Spencer
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Jan 2021 13:38:52 -0600

Hi, Michael,

On Tue, Jan 19, 2021 at 1:56 AM Michael Welzl <[email-masked]> wrote:

> > We've got draft-irtf-panrg-questions-08  and
> draft-irtf-panrg-what-not-to-do-16 off at the IRSG now, and that's two out
> of three of our adopted RG documents.
> >
> Unrelated to agenda planning (and sorry for derailing a bit), I just feel
> like tossing something here, to see how people will react. Probably I'm
> missing out on some recent work that's already along these lines... sorry
> in that case!  But - here it goes...
>
> IMO, based on what I've seen, there's an unnecessary detachment between
> "application layer" (where we don't have these kinds of problems) and "the
> network" (where random devices talk to us, out of the blue).
> That doesn't need to be the case. Just because devices are explicitly
> addressed (which must be the way to go if we should trust them), that
> doesn't force them to operate at the application layer alone. RFC 8803 is a
> fine example of that: a host talks to a proxy, says "please forward my data
> to the real destination, here's the address", and yet, the proxy is
> "allowed" to do TCP things (look at options and so forth). I can't
> understand why we couldn't authenticate (possibly on-path) devices in a
> similar way, even if their role would merely be to provide information?
> E.g., if one of my ISP's boxes could supply my hosts with useful
> information, I'd happily add this box to my host's network configuration,
> using the details that my ISP has given me.
>
> To me, that would seem like a feasible way to do this. I wonder why it's
> not already happening? Is there nothing useful that my ISP's boxes could
> tell my hosts? I doubt that.
>

Yes, that's actually the kind of thing I'm wondering, too.

I guess a first question would be - what recent work do we not know about,
in that space?

Does anyone have pointers?

Best,

Spencer

---

From: "Rayhaan Jaufeerally (IETF)" <[email-masked]>
Date: Wed, 27 Jan 2021 21:20:16 +0100

Greetings,

On Wed, Jan 27, 2021 at 8:39 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> > I have some thoughts, but didn't want to ask to do a presentation if
>> the response to this presentation is known to be "that's not what we want
>> to do" now ...
>> >
Having looked somewhat briefly into this in the past, (sorry if this does
not fit the "work that [we] do not know about" because y'all have already
discussed it), this sounds somewhat like what the goal of the ALTO working
group is https://datatracker.ietf.org/wg/alto/about/.

Specifically, they mention " [devising] a request/response protocol for
allowing a host to benefit from a server that is more cognizant of the
network infrastructure than the host would be", and I imagine this could be
something like supplying multipath information or gateways to other
upstream providers that can be used for steering specific traffic over a
certain path.

I attempted to develop such a system a while ago, but didn't get past an
initial proof of concept for reasons of time constraints when I was still a
student, but I believe that something like SRv6 (
https://tools.ietf.org/html/rfc8402 etc) could be used for a singly homed
end-host to perform some kind of source routing.