Re: [Anima] IPIP in draft-ietf-anima-bootstrapping-keyinfra-07

[Toerless Eckert <[e-mail]>]

Brian,

1. I think the conclusions about IP-in-IP where that it should be in an appendix
   because it would not be MTI (Mandatory to implement). 

2./3.  This was addressed in my shepherd review BRSKI where i folded in the information from
your ani-objectives draft. See my other mail about the status of that review.

You can find the last integrated version of the ani objective text for BRSKI 
in section 3.4 of:

https://raw.githubusercontent.com/anima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap-anima-keyinfra.txt

This was done in may/june. Like for acp-07, i would like to improve this though:

-> I did very much like what the original BRSKI text had, eg: showing also the addresses
   in an example (independent of the fact that as you explain below the examples are not
   correct).

   - Because the addresses are not in the objective field but in the locator-option,
     your proposed text in ani-objectives does not show it. In result i could only
     understand ani-objectives going back and forth with the grasp draft. I think that
     makes it quite unreadable. Thats why the text i put into acp-07 does show the
     whole M_FLOOD format including the location-option and objective.

   - I think your concern was a bit about consistency and duplication. I am not worried
     about consistency given how GRASP is out the door (i hope ;-), and i am happy
     to invest the time for the few additional lines in BRSKI and ACP to make the GRASP explanations
     in BRSKI and ACP be readable (and verifyable for functionality) standalone.
     Especially because of this IMHO confusing bit of scatter-gather encoding that we ended
     up with in GRASP: The name of the service is a parameter to the
     objective, but the address information of the service is in the locator-option field
     outside of the objective...

-> in ani-objectives, the service is called "method", but in grasp-14 it's called
   now objective-value.

Cheers
    Toerless

On Tue, Jul 04, 2017 at 05:32:06PM +1200, Brian E Carpenter wrote:
> Hi,
> 
> I am still trying to figure out what you really want to say in sections 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery Protocol Details.
> 
> 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the pledge needs to know about it?
> 
> 2. The description is wrong anyway; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3 for something that can work.
> 
> 3. In section 3.1.2, as I already pointed out, the proposal is really a misuse of the GRASP discovery response message. Not a problem, we simply replace it with a synchronization response; see https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2. 
> But regardless of that, I am confused by the example locators:
>     locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
>     locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
> 
> The first two are OK. The ports announced by the proxy to the pledges may be different. If the registrar sends  [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the proxy's link-local address and a different port chosen by the proxy.
> 
> But the third locator sent by the Registrar indicates a meaningless link-local address, because it could come from many hops away. At first I thought this was a confusion with the previous (proxy-to-pledge) case, where all addresses must be link-local. But no: this text is just confused, I think:
> 
>    A protocol of 41 indicates that packets may be IPIP proxy'ed.  In the
>    case of that IPIP proxying is used, then the provided link-local
>    address MUST be advertised on the local link using proxy neighbour
>    discovery.  The Join Proxy MAY limit forwarded traffic to the
>    protocol (6 and 17) and port numbers indicated by locator1 and
>    locator2.  The address to which the IPIP traffic should be sent is
>    the initiator address (an ACP address of the Registrar), not the
>    address given in the locator.
> 
> A link local address provided by the Registrar is completely invalid except on the relevant link connected directly to the Registrar. So it definitely must not be given to anybody off that link. At the moment I have no idea how the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from anything else, it mentions a non-existent GRASP message type. I can sort of see what you want to do, but it isn't a codable spec at the moment.
> 
> Maybe you can provide a complete example of the packet flow, where the pledge has link-local address Lp, the proxy has link-local address Lx and ACP address Ax, and the registrar has ACP address Ar. And to make my concern clear, the registrar has the link-local address Lp, by chance the same as the pledge, although on a different LAN.
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]