Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Mark Andrews 

In message 
, Brian 
Dickson writes:
> On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley  wrote:
>
> >
> > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> 
> > wrote:
> > >
> > >
> > > Terry Manderson  wrote:
> > >> B) seek a .homenet special use domain WITHOUT the delegation request
> > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> > >> community to achieve an insecure delegation
> > >
> > >> c) seek a .arpa insecure special use delegation
> > >
> > >> d) go for "B" and if that doesn't work shift to "C"
> > >
> > > Is there some reason we can not proceed with "C", concurrently with (B).
> >
> > I think that would require a new consensus call. There was a lot of work
> > done to get to the point of agreeing on a path forward at the last IETF,
> > and this path would be rather different than that.
> >
> > > This might cause stub resolvers to have to have two cases
> > > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
> > > and attempt interop with SOMETHING.arpa NOW, and it would more clearly
> > > permit "home." to be removed from code.
> > >
> >
> > /chair-hat-off
> >
> > I don’t think we want to have two defaults in our specs. It’s bad enough
> > that we are already going to end up with .home and .homenet depending on
> > the version of code used or forked from, I really don’t want to do 
> > anything
> > that could lead to a third if we can avoid it.
> >
> > - Mark
> >
>
> Taking a STRICTLY devil's advocate position here:
>
> Isn't it the case that the thing that knows what the  label is,
> should be able to masquerade on behalf of anything that isn't aware of the
> divergence of the three possible values for ? If you end up with
> some boxes thinking it is ".home", some ".homenet", and some
> ".homenet.arpa", as long as one of them knows about all three, it should
> be possible to resolve the differences.
>
> The scope of the namespace is "the home network", and never reaches the
> real DNS (roots), so at worst it would be folding the three fake
> namespaces into a unified (three-headed) fake namespace.

Can we please stop with this "and never reaches the real DNS (roots)"
garbage.  Queries for homenet/DS *will* reach the roots.  That is
how DNSSEC validation is designed to work.  They *need* to be
answered with a signed NOERROR NODATA response.  Lots of Linux
distributions ship with DNSSEC validation enabled for on machine
clients and they are also configured to forward to the nameservers
that are returned by DHCP.

These machines behave *exactly* like a validating stub resolver from
the DNSSEC perspective.  This isn't something that will be in the
future.  It is the PRESENT.

> I.e. avoid it if you can, but if you can't, I think the issues are
> solvable, even if they get a little funky/ugly under the hood.
>
> None of that should be visible to users, I don't think.
>
> Brian
>
> P.S. Guide to implementers - never expose multiple handles for the same
> object; over-exuberant users may be tempted to try to "clean up" the
> duplicates.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [homenet] [Anima] prefix assignment

2017-03-29 Thread Pierre Pfister 

> Le 29 mars 2017 à 18:04, Brian E Carpenter  a 
> écrit :
> 
> On 30/03/2017 11:14, Mark Townsley (townsley) wrote:
>> 
>>> On Mar 29, 2017, at 10:04 AM, 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.
>> 
>> I was really pointing out that RFC 7695 could be used independent of HNCP. 
>> 
>> HNCP is just one protocol that uses the RFC 7695 distributed prefix 
>> assignment algorithm (which actually began as extensions to OSPF before HNCP 
>> even existed).
> 
> True. And I don't see any reason why a CASM system including autonomic service
> agents shouldn't be used to supply prefixes for use by an RFC7695 
> implementation.
> So the various tools can fit together.

Absolutely. RFC7695 Applicability Statement (Section 3.) explains that the 
algorithm can be used as
long as participating nodes gets configured with an eventually consistent set 
of non-overlaping prefixes,
which are then used to carve-out sub-prefixes that are assigned to 
link/nodes/objects/toasters.

- If ANIMA provides a protocol capable of configuring nodes with such a set of 
delegated prefixes, RFC7695 can be used. 
- CASM can also be used, as discussed earlier, in order to provision HNCP (by 
the mean of a border router), and hence be used as a provisioning mechanism to 
Homenet border routers.
- If CASM intends to adopt a distributed architecture, and assuming the 
existence of a reliable flooding protocol (AFAIK, grasp would be capable of 
such a thing), RFC7695 could be used in order to reliably carve and assign 
prefixes out of available addressing space.
 
- Pierre

> 
>Brian
>> 
>> - Mark
>> 
>>> 
>>> 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 =-
>>> 
>>> 
>>> 
>>> ___
>>> homenet mailing

Re: [homenet] prefix assignment

2017-03-29 Thread Brian E Carpenter 
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

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

Re: [homenet] [Anima] prefix assignment

2017-03-29 Thread Brian E Carpenter 
On 30/03/2017 11:14, Mark Townsley (townsley) wrote:
> 
>> On Mar 29, 2017, at 10:04 AM, 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.
> 
> I was really pointing out that RFC 7695 could be used independent of HNCP. 
> 
> HNCP is just one protocol that uses the RFC 7695 distributed prefix 
> assignment algorithm (which actually began as extensions to OSPF before HNCP 
> even existed).

True. And I don't see any reason why a CASM system including autonomic service
agents shouldn't be used to supply prefixes for use by an RFC7695 
implementation.
So the various tools can fit together.

Brian
> 
> - Mark
> 
>>
>> 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 =-
>>
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

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

Re: [homenet] prefix assignment

2017-03-29 Thread Brian E Carpenter 
On 30/03/2017 10:04, Juliusz Chroboczek wrote:
>> There's already a thing called an HNCP agent. Why couldn't
>> it be enhanced to negotiate with an upstream ASA for resources?
> 
> Could you please clarify what you mean by "negotiate"?  Current HNCP
> implementations are provided with a bunch of External Prefixes, which they
> then carve into /64, one per prefix.  Are you envisioning a scenario where
> the HNCP implementation actually performs active negotiation on its
> external interfaces?

Yes. But if it's a useless use case, that's fine. I was motivated to
point out that there *really* is no conflict between the homenet work
and Anima, and that they could be complementary if we want.

   Brian

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

Re: [homenet] prefix assignment

2017-03-29 Thread Mark Townsley (townsley) 

> On Mar 29, 2017, at 10:04 AM, 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.

I was really pointing out that RFC 7695 could be used independent of HNCP. 

HNCP is just one protocol that uses the RFC 7695 distributed prefix assignment 
algorithm (which actually began as extensions to OSPF before HNCP even 
existed). 

- Mark

> 
> 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 =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Mark Townsley 

> On Mar 29, 2017, at 10:07 AM, Michael Richardson  
> wrote:
> 
> 
> Terry Manderson  wrote:
>> B) seek a .homenet special use domain WITHOUT the delegation request
>> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
>> community to achieve an insecure delegation
> 
>> c) seek a .arpa insecure special use delegation
> 
>> d) go for "B" and if that doesn't work shift to "C"
> 
> Is there some reason we can not proceed with "C", concurrently with (B).

I think that would require a new consensus call. There was a lot of work done 
to get to the point of agreeing on a path forward at the last IETF, and this 
path would be rather different than that.

> This might cause stub resolvers to have to have two cases
> (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
> and attempt interop with SOMETHING.arpa NOW, and it would more clearly
> permit "home." to be removed from code.
> 

/chair-hat-off

I don’t think we want to have two defaults in our specs. It’s bad enough that 
we are already going to end up with .home and .homenet depending on the version 
of code used or forked from, I really don’t want to do anything that could lead 
to a third if we can avoid it.

- Mark

>> Again, this situation is fluid and as discussions evolve I will provide
>> more information when it is appropriate. In the mean-time I would very
>> much like everyone to take a calming breath and understand that I am
>> taking a very pragmatic view of this concern.
> 
> Thank you!
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment

2017-03-29 Thread Juliusz Chroboczek 
>> Could you please clarify what you mean by "negotiate"?  Current HNCP
>> implementations are provided with a bunch of External Prefixes, which they
>> then carve into /64, one per prefix.  Are you envisioning a scenario where
>> the HNCP implementation actually performs active negotiation on its
>> external interfaces?

> Yes, that's what Brian is suggesting.
> The HNCP daemon would speak GRASP ASA on the "northbound" interface.

Sorry if I wasn't clear.  Would it merely request address space and handle
it out using HNCP, or would it actively renegotiate address space in
response to HNCP events?

If the latter -- why?

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

Re: [homenet] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Mark Townsley 
Many Thanks for posting this, Terry.

Homenet,

As Terry said, these options are still very fluid and may come or go. That 
said, Ray and I talked this over and believe Option B fits well within the 
spirit of the consensus call made at IETF 97 to redact and replace .home with 
.homenet (understanding at the time that it could be more difficult 
process-wise than if we requested .homenet.arpa). 

- Mark


> On Mar 28, 2017, at 12:32 PM, Terry Manderson  
> wrote:
> 
> Dear HOMENET and DNSOP WG(s),
> 
> Wearing the INT AD hat.
> 
> Firstly, thank you to the DNSOP WG for the deep review, thoughts, and 
> considered responses to my request for review.
> 
> Secondly, my apologies for not sharing my throughs before the HOMENET 
> session. It would have been impractical to do so as this is a very (VERY) 
> fluid situation with IETF leadership also engaged in discussions.
> 
> This is simply an iteration of my description of the current situation as 
> delivered yesterday. Do be aware that conversations are continuing and you 
> should NOT take this as a declarative statement. During the HOMENET WG 
> session I specified that for this topic I am comfortable answering _ 
> clarifying _ questions. The same applies here. My answers may or may not 
> change due to the fluid nature of the concern and I hope you appreciate that.
> 
> My summary of the situation is this.
> 
> 1) .homenet _COULD_ be added to the special use domain registry based on 
> RFC6761 
> 
> 2) The expected future operation of HOMENET resolution for DNSSEC validating 
> stub resolvers requires a break in the DNSSEC chain of trust.
> 
> 3) To achieve "2", the document _additionally_ asks IANA to insert an 
> insecure delegation into the root zone
> 
> 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to 
> put an entry into someone else's registry (the root zone), and will require a 
> set of collaborative discussions with the ICANN community and a new process 
> that handles this situation. There are no expectations that this process will 
> be defined in a reasonable time for the uses of HOMENET.
> 
> 
> Options, possibly not an exhaustive list
> 
> A) seek a .homenet special use domain with the request for an insecure 
> delegation in the root zone. (This is what the document asks for NOW, and 
> here we are)
> 
> B) seek a .homenet special use domain WITHOUT the delegation request AND ask 
> the IETF/IESG/IAB to commence the discussion with the ICANN community to 
> achieve an insecure delegation
> 
> c) seek a .arpa insecure special use delegation
> 
> d) go for "B" and if that doesn't work shift to "C"
> 
> 
> Each of these have different positive and negatives in a raw technical sense, 
> UI design desires, and policy and political frames.
> 
> Again, this situation is fluid and as discussions evolve I will provide more 
> information when it is appropriate. In the mean-time I would very much like 
> everyone to take a calming breath and understand that I am taking a very 
> pragmatic view of this concern.
> 
> Cheers,
> Terry
> INT AD
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] prefix assignment

2017-03-29 Thread Michael Richardson 

Juliusz Chroboczek  wrote:
>> There's already a thing called an HNCP agent. Why couldn't
>> it be enhanced to negotiate with an upstream ASA for resources?

> Could you please clarify what you mean by "negotiate"?  Current HNCP
> implementations are provided with a bunch of External Prefixes, which they
> then carve into /64, one per prefix.  Are you envisioning a scenario where
> the HNCP implementation actually performs active negotiation on its
> external interfaces?

Yes, that's what Brian is suggesting.
The HNCP daemon would speak GRASP ASA on the "northbound" interface.
It wouldn't necessarily speak HNCP.

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





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

Re: [homenet] prefix assignment

2017-03-29 Thread Michael Richardson 

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment

2017-03-29 Thread Juliusz Chroboczek 
> There's already a thing called an HNCP agent. Why couldn't
> it be enhanced to negotiate with an upstream ASA for resources?

Could you please clarify what you mean by "negotiate"?  Current HNCP
implementations are provided with a bunch of External Prefixes, which they
then carve into /64, one per prefix.  Are you envisioning a scenario where
the HNCP implementation actually performs active negotiation on its
external interfaces?

-- Juliusz

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

Re: [homenet] prefix assignment

2017-03-29 Thread Juliusz Chroboczek 
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.

HNCP just doesn't care.  HNCP has a notion of "External Connection", and
an External Connection may provide one or more External Prefixes.  HNCP
will assign to each link in the HNCP one /64 from each External Prefix.

HNCP doesn't care where these External Connection TLVs come from, but it
is my understanding that there is WG consensus that DHCPv6-PD is the
default mechanism.  I don't think there's anything in any of our RFCs that
would prevent an implementation from obtaining External Prefixes using
a different protocol, e.g. manual configuration, a proprietary
provisioning protocol or even algorithmically derived from an IPv4 address
(as with 6rd).

Both implementations of HNCP are easy to extend with a different mechanism
for obtaining External Prefixes, should you wish to experiment.

-- Juliusz

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

Re: [homenet] prefix assignment

2017-03-29 Thread Brian E Carpenter 
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

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

[homenet] ask for .arpa

2017-03-29 Thread Michael Richardson 

Terry Manderson  wrote:
Terry> There is no policy or technical barrier to proceeding with
Terry> SOMETHING.arpa. Procedurally that, of course, would necessitate some 
WG
terry> discussion and consensus.

...
Terry> c) seek a .arpa insecure special use delegation

mcr> This might cause stub resolvers to have to have two cases
mcr> (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
mcr> and attempt interop with SOMETHING.arpa NOW, and it would more clearly
mcr> permit "home." to be removed from code.

I believe that HOMENET should proceed immediately with asking the IAB for
.arpa.

I think that getting "home." removed from implementation is pretty important.

let's do this ask concurrently with deciding what  is.

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





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

Re: [homenet] prefix assignment

2017-03-29 Thread Brian E Carpenter 
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 =-
> 
> 
> 

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

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Terry Manderson 
Hi Michael,

There is no policy or technical barrier to proceeding with SOMETHING.arpa. 
Procedurally that, of course, would necessitate some WG discussion and 
consensus.

Cheers
Terry

On 30/03/2017, 1:07 AM, "DNSOP on behalf of Michael Richardson" 
 wrote:


Terry Manderson  wrote:
> B) seek a .homenet special use domain WITHOUT the delegation request
> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> community to achieve an insecure delegation

> c) seek a .arpa insecure special use delegation

> d) go for "B" and if that doesn't work shift to "C"

Is there some reason we can not proceed with "C", concurrently with (B).
This might cause stub resolvers to have to have two cases
(SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
and attempt interop with SOMETHING.arpa NOW, and it would more clearly
permit "home." to be removed from code.

> Again, this situation is fluid and as discussions evolve I will 
provide
> more information when it is appropriate. In the mean-time I would very
> much like everyone to take a calming breath and understand that I am
> taking a very pragmatic view of this concern.

Thank you!

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






smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Terry Manderson 
Hi James,

Q1. Both. The root zone, as a registry, is not an IETF registry.

Q2. My guess, and I am really guessing here, that if a process were to be 
created by the ICANN community to accept such requests from the IETF, it would 
be encompassing of both.

Cheers
Terry 


On 30/03/2017, 12:48 AM, "homenet on behalf of james woodyatt" 
 wrote:



q1. What precisely about “3” is not covered in IETF policy terms? That the 
document directs IANA to request a delegation in the root zone? Or that the 
document directs IANA to request an *insecure* delegation in the root zone, 
whereas a secure delegation
 *would* be adequately covered? Or both of these?


q2. If the answer to q1 is that both aspects of “3” are not covered in IETF 
policy terms, and that each one will require a set of collaborative discussions 
with the ICANN community and new processes that handle each of these 
situations, are there any expectations
 about which of the two processes, if there are two and not just one, can 
be defined in a workable period of time for HOMENET?



--james woodyatt 








smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread Michael Richardson 

Terry Manderson  wrote:
> B) seek a .homenet special use domain WITHOUT the delegation request
> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN
> community to achieve an insecure delegation

> c) seek a .arpa insecure special use delegation

> d) go for "B" and if that doesn't work shift to "C"

Is there some reason we can not proceed with "C", concurrently with (B).
This might cause stub resolvers to have to have two cases
(SOMETHING.arpa, and .homenet) eventually, but at least we could deploy
and attempt interop with SOMETHING.arpa NOW, and it would more clearly
permit "home." to be removed from code.

> Again, this situation is fluid and as discussions evolve I will provide
> more information when it is appropriate. In the mean-time I would very
> much like everyone to take a calming breath and understand that I am
> taking a very pragmatic view of this concern.

Thank you!

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





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

Re: [homenet] prefix assignment

2017-03-29 Thread Michael Richardson 

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

2017-03-29 Thread George Michaelson 
sign it with a bad key or bad DS. this goes to SERVFAIL and its NXDOMAIN.

-G

On Wed, Mar 29, 2017 at 9:48 AM, james woodyatt  wrote:
> Hi Terry,
>
> Clarifying questions here...
>
> On Mar 28, 2017, at 12:32, Terry Manderson 
> wrote:
>
>
> My summary of the situation is this.
>
> 1) .homenet _COULD_ be added to the special use domain registry based on
> RFC6761
>
> 2) The expected future operation of HOMENET resolution for DNSSEC validating
> stub resolvers requires a break in the DNSSEC chain of trust.
>
> 3) To achieve "2", the document _additionally_ asks IANA to insert an
> insecure delegation into the root zone
>
>
> 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to
> put an entry into someone else's registry (the root zone), and will require
> a set of collaborative discussions with the ICANN community and a new
> process that handles this situation. There are no expectations that this
> process will be defined in a reasonable time for the uses of HOMENET.
>
>
> q1. What precisely about “3” is not covered in IETF policy terms? That the
> document directs IANA to request a delegation in the root zone? Or that the
> document directs IANA to request an *insecure* delegation in the root zone,
> whereas a secure delegation *would* be adequately covered? Or both of these?
>
> q2. If the answer to q1 is that both aspects of “3” are not covered in IETF
> policy terms, and that each one will require a set of collaborative
> discussions with the ICANN community and new processes that handle each of
> these situations, are there any expectations about which of the two
> processes, if there are two and not just one, can be defined in a workable
> period of time for HOMENET?
>
> --james woodyatt 
>
>
>
>
> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

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