>
-----------------------------------------------------------------------------
> Section 4. 1)
> a.1) Suggest to change title to "Proxying Details (Plege - Proxy -
> Registrar)" because the section does not only discuss the proxy but
> also the aspects/reqirements of proxying relevant to Client and
> Registrar.
> a.2) paragraph 1: "configured on the Proxy" append: "or automatically
> discoverded (e.g.: via GRASP, see below)
In fact, we never want it configured in an autonomic network, it should
always be discovered.
> b) Add: This section defines a statefu proxy which is therefore called
> a "circuit" proxy.
okay.
> c) Simplify whole paragraph with "(In a completely autonomic
> network...)" - this discussion is not specific to AN. E.g.:
> Registrars are assumed to have logically a locally integrated Proxy to
> support directly (subnet) connected Pledges - because Registrars
> themself does not define any functions for Pledges to discover
> them. Such a logical local proxy does not need to provide actual TCP
> proxying (just discovery) as long as the Registrar can operate with
> subnet (link) local addresses on the interfaces where Pledges may
> connect to.
done
> d) "to discovery the" -> "to discover the"
already fixed I think.
> e) Paragraph starting with: "If the Proxy joins an Autonomic Control
> Plane" Suggest following replacement:
> In the ANI, the Autonomic Control Plane (ACP) secured instance of
> GRASP (<ref>) MUST be used for discovery of ANI Registrar ACP addresses
> and ports by ANI Proxies. The TCP leg of the proxy connection between
> ANI Proxy and ANI Registrar therefore also runs across the ACP.
> (separate because it would apply for any GRASP learning, not only
> ACP):
> If GRASP is used by proxies for discovery of Registrars (ACP or
> not), the proxy can also learn the proxy mechanism (Circuit Proxy
> vs. IPIP encapsulation or other)
> (there is no negotiation in GRASP, therefore "agreed" as in current
> text is not a good choice of word).
okay.
> f) "SHOULD be the same as on the registrar in order for the proxy to
> remain stateless". Does such a proxy makes sense when it is not
> stateless ? Aka: should this not be a MUST instead of a SHOULD ?
I can imagine ways to not use the same port, while still avoiding
O(number-of-pledges) storage of state. But it involves messing with
packet headers in a way that I find distasteful. That's why I write SHOULD.
>
-----------------------------------------------------------------------------
> Section 4. 2)
> "In order to permit the proxy functionality to be implemented on the
> maximum variety of devices... with available capabilities for the
> proxy function similar to many class 2 IoT devices"
> This IMHO is an incorrect assumption. I am not aware of any network
> device in ANIMAs "well managed network" charter" that would today fall
> into class 2. I was and am often extremely annoyed how underpowered
> control plane of multi-terrabit switches are but those too don't get
> down to that level. Even OpenWRT small home rotuers (outside scope of
> ANIMA) don't go below 4 MByte these days.
Yes, but I'm not talking about using the whole control plane CPU:
-> "available capabilities for the proxy function"
we gotta fit into whatever is left over, or product management will kick our
code out next time there is a code space crunch.
As far as I can tell, due to SDN outsourcing the control protocols
(like BGP and OSPF and even), and the rest being in forwarding-element
hardware, one COULD probably get away with an OpenWRT scale CPU as the
control plane CPU for a L2/L3-aware switch with hundreds and hundreds of
ports...
> Here are statements i could support/recommend:
> - Registrars must support the proxy method supportable by the type of
> proxies it needs to support. If pledges could be IoT class 2, then IPIP
> would be a better solution for them than a CP circuit proxy. Note that
> in ANI adopted to class 2 IoT or similar "mesh network" solutions,
> Plege become proxies proxy and therefore IoT class 2 pledges imply also
> the need to support IoT class 2 proxies.
So, it matters not what the pledge is.
The Pledge in this document is always doing HTTPS over TCP over Link-Local
IPv6, and never needs to know what the relay protocol is.
So, I don't agree with your paragraph here.
>
-----------------------------------------------------------------------------
> Section 4.1 1)
> a) "[RFC4941] temporary addresses is encouraged...." Please remove or
> add text explaining why. Given how a pledge is happy to spill it's
> IDevID to everyone claiming to be a proxy i am not sure what benefit
> privacy addresses have, and they are additional implementation work for
> pledges, whereas link-local (permanent) addresses are always
> required. And changing addresses makes diagnostics harder.
> I also am not even sure if RFC4941 is even creating additional
> link-local (temporary) addresses. I don't even think so. And all the
> concerns RFC4941 discusses about correlating traffic is hardly
> applicable to what the link-local address is used for. link local GASP
> discovery, BRSKI-TCP, maybe later some ACP tunnell..
We had a long discussion about this at design team meetings a year plus ago,
and I tend to AGREE WITH YOU.
Note that we temporary addresses do not require any long term storage
(vs privacy enhanced stable addresses)
Our discussion, you might recall centered on the question of whether the
connection should be initiated from the JRC->Pledge (as a result of some
signal) or the other way around. The reasoning is that the <TLS1.2 connection
reveals the ClientCertificate first.
Note that TLS1.3 will keep contents of the certificates transmitted private
against passive eavesdroppers, while TLS 1.2 will not.
If you feel strongly about removing this recommendation, I'd like to make
this a WGLC issue (in the tools issue tracker), so that we can point to the
discussion when we are asked why we aren't mandating them.
I wrote a Privacy Concern section here:
https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-01#section-10
tell me if you'd like to copy and paste some of that into a Privacy
Considerations section in BRSKI.
>
-----------------------------------------------------------------------------
> Section 4.1 2)
>> Methods SHOULD be run in parallel to avoid head of queue problems
>> wherein an attacker running a fake proxy or registrar can operate
>> protocol actions intentionally slowly.
> methods == circuit proy, IPIP, ... ? would also be recommended to try
> different proxies in parallel, right ?
No methods refers to M_GRASP vs optional things like mDNS or IPv4.
Changes too long to post.
>
-----------------------------------------------------------------------------
> Section 4.1 1)
> a) The requirement to do proxy discovery via GRASP was already written
> in 4.1. Please remove. Please use term DULL GRASP instead of just
> GRASP.
okay.
> I would also suggest to revisit the name of the objective. The
bikeshed.
> Here is suggested text:
> 180000, [ ["SRV.brski-proxy", 4, 1, "https" ], [O_IPv6_LOCATOR,
But, we didn't register a service called "brski-proxy", so that would be wrong.
I don't think we are interested in registered that name.
I didn't understand your CDDL.
> objective-value = method
> method = "https" ; or future methods ; CoAP not considered yet, see below
Like why would I do that?
>
-----------------------------------------------------------------------------
> Section 4.2) 1)
> a) Append: Therefore the "coap" method in the previous section was only
> used for the example but is not included in the CDDL definition of the
> GRASP objective above.
That's why I didn't include it as an example.
>
-----------------------------------------------------------------------------
> Section 4.3) 1)
> a) I would suggest removing this section and putting the requirement
> into 4.1 together with the rest of the requirments.
I agree that the section is redundant.
> Section 4.3) 1)
I guess you mean 4.4.
> a) Suggest to move the first paragraph with requirements to section 4.1
> b) Requirements must include:
> ANI Registrars MUST announce their Registrar service via the ACP
> instance of GRASP. They MUST support ANI TLS circuit Proxy and
> therefore BRSKI across HTTPS/TLS native across the ACP. ANI Registrars
> MAY support the IPIP proxy method by implementing IPIP tunneling for
> their HTTPS/TLS traffic across the ACP. ANI Proxies MUST support GRASP
> discovery of Registrars .
okay.
> c) The following is fixed up text for the remainder of 4.3 to solve the
> following issues: - change of GRASP objective-name
> (SRV.brski-registrar) and methods ("https", "https-ipip" as well as
Point not well taken.
> coap for examples sake).
>- changed address of registrar to be an actual ACP address
Because fda3:79a6:f6ee:0000:0200:0000:6400:0001 (I missed a zero!)
is somehow not a ULA?
> - GRASP example was cut off/incomplete
I think only the closing ]], which is confusing because the artwork
ends with ]]>. I've moved it into all into new files:
https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/jrcgrasp-cddl.txt
https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/jrcgrasp-example.txt
https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/proxygrasp-cddl.txt
https://github.com/anima-wg/anima-bootstrap/blob/toerless-terminology-comments/proxygrasp-example.txt
You'll find that there is a "pencil" icon on each page that lets you edit the
example or CDDL right there and send it as a pull request.
Please if you could seperate:
a) fixes to the syntax of the CBOR diag notation, or CDDL
from:
b) proposals to change any of the bits on the wire (including changing
the name of the objective).
I'm skipping to the next section.
> a) The above "transport-proto /= 41" is technically an update to
> GRASP RFC which allows only UDP / TCP. There is some process around
really?
QUESTION to Brian.
> c) I am not sure how we solve the problem of multiple IPIP Proxies on
> a single LAN fighting to own h'fe80::1234. It seems to me we would have
You are solving a problem that does not exist.
You are right that IPIP is inadequately described at this point.
If only I was accepting a few dozen github pull requests rather than
this hundred page long email...
I wonder if we could remember that this is a Proposed Standard?
> "The Join Proxy SHOULD do a GRASP M_NEG_SYN for each interface
> which they wish to relay traffic, as this allows the Registrar to do
> any static tunnel configuration that may be required"
> Please insert implementable GRASP objective specifications for
> this step here...
It's an error.
M_NEG_SYNC was replaced with M_FLOOD. I've removed that.
Version -12 submitted at this point.
https://goo.gl/Xyd5N2
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
