On Fri, Jun 01, 2018 at 02:10:27PM -0400, Michael Richardson wrote:
>
> Toerless Eckert <[email protected]> wrote:
> > Anyhow. let me just list what i think is necessary to fi up the GRASP
> so it works
> > for both TLS and IPinIP.
>
> You seem to write TLS in a few places where TCP is actually called for.
> To be more precise, it's static 1:1 destination NAT66, aka "port-forward"
Hmm. I had only written TCP and then i saw your text using the term "ANI TLS
circuit proxy",
so then i was changing my proposed text to be compliant with that.
> > e) Add at end of 4.1.1 suggested text:
>
> > The transport-proto of the locator-option indicates the mechanism(s)
> > supported by the proxy to the pledge. IPPROTO_TCP indicates the
> > mandatory ANI TLS circuit proxy. IPPROTO_IPV6 indicates the optional
> > IPinIP proxy, see Appendix C. IPPROTO_UDP would indicate a future
> > CoAP mechanism, see Section 4.2. For IPPROTO_IPV6, proto-number
> > MUST be 0.
>
> > The above example shows a proxy supporting both ANI TLS circuit proxy
> > and IP in IP proxy.
>
> This would seem to be the only needed text to me.
>
> > b) Please consider improving the example as above for 4.1.1:
> > - lead in text for example
> > - example title
> > - [ [ objective, locator-option ] ] structure fix
> > - Ideally also include both TLS and IPinIP options in example
>
> > Also:
> > - I find the use of port 80 in the example highly confusing given how
> > the TCP connection MUST use TLS. Please change to AB80 (anything but
> > 80).
>
> okay.
>
> > So, your full example locators with objectives would be:
>
> > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 6,
> 443]] ]
> > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fd45:1345::6789, 17,
> 5683] ]
> > [["AN_join_registrar", 4, 255], [O_IPv6_LOCATOR, fe80::1234, 41, 0] ]
>
> > Is this join registrar supporting ANI TLS proxy ?
> > Aka: i can't distinguish for the TCP locator whether it just indicates
> > a permitted TCP port for the IPinIP proxy or whether it indicates
> > the TCP port supported for IPinIP. And even if the proxy supports both,
> > its not clear to me that the TCP ports for "native" would be the same as
> > for IPinIP. Maybe its different code-paths == different ports.
>
> I'm sorry, I don't even understand the problem.
> Maybe someone else can translate for me.
Ok, i think was also confused yesterday, but thats all because of the bloody
IPPROTO_IPV6 in 4.1.1.
So, if i understand it correctly after a fresh coffee, we should completely
eliminate
IPPROTO_IPV6 from 4.1.1, but we still need it for 4.3:
So, the Pledge would never need to know anything about IPinIP, it would always
only see the same type of Proxy announcement for AN_Proxy with BRSKI-TLS, or in
the future BRSKI with UDP for use with CoAP. the only distinguishable
difference would be the LL address the proxy announces:
So, this would be an example GRASP message from a circuit proxy. The
LL address in the locator is typically its "own" native link-local address,
ike the one from which it originates this DULL GRASP message:
a) [M_FLOOD, 7234567, h'fe80::1', 180000,
[ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1, 6, 443] ] ]
Now instead, the proxy operates as an IPinIP proxy and the announcement
might look like this:
b) [M_FLOOD, 7234567, h'fe800::1', 180000,
[ ["AN_Proxy", 4, 255 ], [O_IPv6_LOCATOR, fe80::1234, 41, 4443] ] ]
For the Pledge, no difference in its own behavior. But:
4.1.1 says right now, that the port-number is allocated by the Proxy.
And the same is actually true for the LL address in the locator.
But: If the Proxy is operating as LL proxy, then it is not the proxy
allocating the LL address and the port-number, but instead it is the
Registrar,
the Proxy is just taking the information from the registrar GRASP
announcement and copies it into its b) announcement to the
Pledge - and of course set up locally the appropriate state: listen to
fe80::1234 and forward packets received for it including filtering for
only TCP packets to port 4443.
Which still begs the question how the Proxy learned about the registrar to
be able to create both the b) announcement to the Pledge and its own state.
4.3 argues seemingly that IPinIP proxy would need to receive the following
two locators to get this information:
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 4443]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
Locator3 would tell the eProxy that the registrar supports IPinIP, and
locator1 tells the Proxy that the IPinIP registrar support TLS BRSKI over
port 4443 across IPinIP.
And i said that in the way BRSKI-14 is written, individual GRASP
AN_Join_registrar
objecties do not have a way to encode these two locators together into a
single objective. And also that i think you can not simply announce these
locators separately via two GRASP AN_Join_register objectives because
that is not only bad style, but also ambiguous. A GASP objective with
locator1 would by itself not allow for proxies to know whether it is meant
to support curcit-proxy operations AND/OR IPinIP operations. And a Registrar
might support both curcuit-proxy Pledges AND IPinIP pleges but not on the
same TCP port, but potentially on different ports.
So, threefore i concluded, that the AN_Join_registrar GRASP objective needs
to have an encoding where all he necessary locators can be included in
a way that it is unambiguously differentiated from an AN_Join_registrar
announcement indicating support for circuit proxies.
So, what i proposed was that the locator-option field indicates the
primary locator for the supported proxy model. Aka: for "native" TCP/TLS
or UDP, its the locators with proto 6 or 17. For IPinIP its proto 41.
Then only the announcement for IPinIP will need to have one or more additional
locators, which indicate the proxy method and ports supported inside of
IPinIP. And the text proposed to encode those into the objective-value
field of the GRASP objective:
> [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000,
> [ ["AN_join_registrar", 4, 255 ],
> [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 443]
> ],
> [ ["AN_join_registrar", 4, 255,
> [[O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001', 6, 4443],
> [O_IPv6_LOCATOR, h'fda379a6f6ee0::200000064000001',17, 5683]]
> ],
> [O_IPv6_LOCATOR, fe80::1234, 41, 0]
> ]
> ]
The first AN_join_registrar objective indicates this registrar supports
circuit-proxies,
aka: native TLS connections across the ACP on TCP port 443.
The second AN_join objective indicates it support IPinIP. The two additional
locators in this objective indicate that TCP/TLS on port 4443 is supported
across IPinIP and the second one that probably CoAP/UDP is supported across
port 5683 (i have seen no explanation in BRSKI-14 what/how UDP would be used,
so i assume its for CoAP. Probably CoAP/dTLS/UDP ?).
Does this explains it better ?
Cheers
Toerless
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works | network architect
> [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
