Re: [Anima] prefix assignment
On 30/03/2017 10:38, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> I just don't see the point of the ASA here. > > > There's already a thing called an HNCP agent. Why couldn't > > it be enhanced to negotiate with an upstream ASA for resources? > > Because it's already done. It's called DHCPv6. > It already has extensive running code :-) > It's not even that complex. All true. But it isn't designed for negotiation as far as I know, just a request/response. > I would love to request address space via ASA from the DHCPv6 server. > That would all happen within the ISP's ACP though. Agreed, that is a little higher up the food chain. Maybe that is as close to the user as an ASA will get. I don't really care; I just wanted to explore the way we might fit our various tools together. > Right now (on DSL lines), the address space mostly comes via radius. > Which is to say that the problem has been centralized by MBS builders into > being someone else's problem. Advertising the address space is often done by > OSPFv3, but there are additional things that would be easier for the DHCPv6 > server to do, such as the DNS delegations that homenet is working on > finishing. Yes, indeed, and then we could discuss how the radius server gets new address space when it runs out. > I think that CASM could very nicely define/extend the prefix ASA to deal with > DNS reverse names, and as the RIRs (George) said, better link the delegated > prefix to clear ownership records. Yes, by defining a full set of relevant objectives. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] prefix assignment
Brian E Carpenter wrote: >> I just don't see the point of the ASA here. > There's already a thing called an HNCP agent. Why couldn't > it be enhanced to negotiate with an upstream ASA for resources? Because it's already done. It's called DHCPv6. It already has extensive running code :-) It's not even that complex. I would love to request address space via ASA from the DHCPv6 server. That would all happen within the ISP's ACP though. Right now (on DSL lines), the address space mostly comes via radius. Which is to say that the problem has been centralized by MBS builders into being someone else's problem. Advertising the address space is often done by OSPFv3, but there are additional things that would be easier for the DHCPv6 server to do, such as the DNS delegations that homenet is working on finishing. I think that CASM could very nicely define/extend the prefix ASA to deal with DNS reverse names, and as the RIRs (George) said, better link the delegated prefix to clear ownership records. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] prefix assignment
On 30/03/2017 09:16, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Where you want to plug in an ASA (autonomic service agent) is anywhere > > you want plug in some intelligence to govern an automatic process. > > Intelligence, for example, to figure out what to do if the user side > > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > > a compromise at /56 and then PD does its thing. But we didn't want > > to exclude a scenario where PD isn't available, hence a flag is > > included. > > To put this is pseudo-(monty)pythonesq: > > Customer: Hi, I'd like to buy a parrot. > Store: Would you like a Blue Parrot or a Red Parrot? > Customer: I'd like a Blue Parrot. > Store: I'm sorry, but we don't sell Parrots. No, it's not really Pythonesque but negotiation is allowed to fail. > I just don't see the point of the ASA here. There's already a thing called an HNCP agent. Why couldn't it be enhanced to negotiate with an upstream ASA for resources? > If DHCPv6-PD isn't available, then it's not a compliant ISP connection > (RFC7204) and it's outside of the scope of homenet to begin with. No disagreement; the idea was simply to ensure that the GRASP objective can communicate that PD is or isn't available. If PD is required in a particular scenario then that parameter will always be set True. > > About the domain boundary: > > >> I don't think that the ISP can trust to have code controlled by end > users > >> running in their ACP domain. > > > Right. But in ISP-provided CEs this could presumably be fixed, because > > that code would be locked down. In a store-bought CE, isn't this exactly > > where BRSKI will help us? There is certainly an issue for home-made CE > > images, but they will be a tiny minority of users. > > No, BRSKI doesn't help the ISP feel safe that the code I am running > on my store-bought CE won't attempt to mess with their network. Yes, I see that. (Unless of course we get into much more complex validation and authorization stuff, which seems unlikely to fly.) Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] prefix assignment
Brian E Carpenter wrote: > Where you want to plug in an ASA (autonomic service agent) is anywhere > you want plug in some intelligence to govern an automatic process. > Intelligence, for example, to figure out what to do if the user side > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > a compromise at /56 and then PD does its thing. But we didn't want > to exclude a scenario where PD isn't available, hence a flag is > included. To put this is pseudo-(monty)pythonesq: Customer: Hi, I'd like to buy a parrot. Store: Would you like a Blue Parrot or a Red Parrot? Customer: I'd like a Blue Parrot. Store: I'm sorry, but we don't sell Parrots. I just don't see the point of the ASA here. If DHCPv6-PD isn't available, then it's not a compliant ISP connection (RFC7204) and it's outside of the scope of homenet to begin with. > About the domain boundary: >> I don't think that the ISP can trust to have code controlled by end users >> running in their ACP domain. > Right. But in ISP-provided CEs this could presumably be fixed, because > that code would be locked down. In a store-bought CE, isn't this exactly > where BRSKI will help us? There is certainly an issue for home-made CE > images, but they will be a tiny minority of users. No, BRSKI doesn't help the ISP feel safe that the code I am running on my store-bought CE won't attempt to mess with their network. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] prefix assignment
OK, I'll front-post.
Where you want to plug in an ASA (autonomic service agent) is anywhere
you want plug in some intelligence to govern an automatic process.
Intelligence, for example, to figure out what to do if the user side
asks for a /48 and the ISP offers a /60. So the ASA might negotiate
a compromise at /56 and then PD does its thing. But we didn't want
to exclude a scenario where PD isn't available, hence a flag is
included.
About the domain boundary:
> I don't think that the ISP can trust to have code controlled by end users
> running in their ACP domain.
Right. But in ISP-provided CEs this could presumably be fixed, because
that code would be locked down. In a store-bought CE, isn't this exactly
where BRSKI will help us? There is certainly an issue for home-made CE
images, but they will be a tiny minority of users.
Brian
On 30/03/2017 04:04, Michael Richardson wrote:
>
> This discussion started in a private thread, so I'll try to bring people
> up-to-date by repeating and moving around text.
>
> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
> to do distributed prefix allocation. This is very much in the space of
> *coordinated* address management.
>
> (My take, BTW, is that CASM should be considered the first spin-off WG
> From ANIMA...)
>
> Mark and Brian discussed how HNCP does prefix distribution within Homenet.
>
> Brian then suggests:
>
> brian> But if the CE includes a little autonomic service agent (ASA) which
> brian> is in the ISP's security domain (not the SOHO domain), it can act for
> brian> HNCP to solicit address space from the ISP. That's the southern side
> brian> of the CASM model and the northern side of HNCP.
>
> I asked a simple question: don't we have DHCPv6 for this?
>
> I also then asked:
>
> > a) the CPE device is now part of the ISP's ACP.
> > That's okay if the CPE device is owned by the ISP and/or the CPE device
> > includes some kind of trusted computation environment.
> > {But a CPE owned by the ISP, might not be trusted by the home owner,
> > so another router in between would be needed,
>
> Brian answered:
> > Really? Why not?
>
> I don't think that the ISP can trust to have code controlled by end users
> running in their ACP domain.
>
> I also think that many end-users will be quite reasonably upset that their
> ISPs can snoop on their internal traffic. This may in fact violate many
> work-at-home agreements; which is often the case of why you see multiple
> routers/firewalls in documents like
> https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.
>
> (Fred had more interesting diagrams in presentations, which I could dig up)
>
> >> b) DHCPv6 PD is already the protocol that solves prefix allocation
> across
> >> trust boundaries.
>
> > Indeed. That's why we have "PD supported" as a Boolean property of the
> > PrefixManager objective. There's no intention to undermine PD.
>
> Why do I need to run a protocol in order to find if I can run a protocol,
> when DHCP has the same mechanism already. And use of DHCPv6 itself is well
> defined in cable and DSL connections already.
>
> >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that
> deals with
> >> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the
> north.
>
> > Yes, the DSLAM is definitely a good place to put one.
>
>
> >> North of the ISP's device would be the ISP's (distributed) IPAM.
> >> GRASP/ASA-Prefix would be the protocol between.
>
> > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
> > complementary not competitors.
>
> I don't see you saying that.
>
> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
> in the home) such that they interact directly, rather than using PD. You
> say this right here:
>
> brian> But if the CE includes a little autonomic service agent (ASA) which
>
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] prefix assignment
This discussion started in a private thread, so I'll try to bring people
up-to-date by repeating and moving around text.
The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
to do distributed prefix allocation. This is very much in the space of
*coordinated* address management.
(My take, BTW, is that CASM should be considered the first spin-off WG
From ANIMA...)
Mark and Brian discussed how HNCP does prefix distribution within Homenet.
Brian then suggests:
brian> But if the CE includes a little autonomic service agent (ASA) which
brian> is in the ISP's security domain (not the SOHO domain), it can act for
brian> HNCP to solicit address space from the ISP. That's the southern side
brian> of the CASM model and the northern side of HNCP.
I asked a simple question: don't we have DHCPv6 for this?
I also then asked:
> a) the CPE device is now part of the ISP's ACP.
> That's okay if the CPE device is owned by the ISP and/or the CPE device
> includes some kind of trusted computation environment.
> {But a CPE owned by the ISP, might not be trusted by the home owner,
> so another router in between would be needed,
Brian answered:
> Really? Why not?
I don't think that the ISP can trust to have code controlled by end users
running in their ACP domain.
I also think that many end-users will be quite reasonably upset that their
ISPs can snoop on their internal traffic. This may in fact violate many
work-at-home agreements; which is often the case of why you see multiple
routers/firewalls in documents like
https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.
(Fred had more interesting diagrams in presentations, which I could dig up)
>> b) DHCPv6 PD is already the protocol that solves prefix allocation across
>> trust boundaries.
> Indeed. That's why we have "PD supported" as a Boolean property of the
> PrefixManager objective. There's no intention to undermine PD.
Why do I need to run a protocol in order to find if I can run a protocol,
when DHCP has the same mechanism already. And use of DHCPv6 itself is well
defined in cable and DSL connections already.
>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals
with
>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the
north.
> Yes, the DSLAM is definitely a good place to put one.
>> North of the ISP's device would be the ISP's (distributed) IPAM.
>> GRASP/ASA-Prefix would be the protocol between.
> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
> complementary not competitors.
I don't see you saying that.
I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
in the home) such that they interact directly, rather than using PD. You
say this right here:
brian> But if the CE includes a little autonomic service agent (ASA) which
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
