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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Jul 2017 17:32:06 +1200

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 5 Jul 2017 14:42:59 +0000

Brian, I’m out for a couple of weeks but wanted to thank you for this note. 

Michael Richardson will likely have good comments but for now I’ve set a calendar event to catch up when I return and also have created a github issue to track this. 
	https://github.com/anima-wg/anima-bootstrap/issues/22

- max

> On Jul 3, 2017, at 11:32 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 6 Jul 2017 01:05:53 +0200

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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Jul 2017 13:42:29 +1200

>    because it would not be MTI (Mandatory to implement). 

That makes sense. But the text is still a bit confusing because it doesn't make that
clear in the main text. However, before we resolve that, I need to understand
how it's really supposed to work.

>      whole M_FLOOD format including the location-option and objective.

I understand that; showing example packets is an excellent idea. (But the reader
must understand GRASP anyway.) The reason I'm trying to figure out exactly what
happens in IPIP is exactly so that I can generate example packets from code; if they
don't agree with what you expect, we would then have a real problem to solve.
> -> in ani-objectives, the service is called "method", but in grasp-14 it's called

Right. It's the value of the objective, which is a generic concept in GRASP. But what
the value actually is depends on the syntax and semantic of the individual objective.
That's actually your fault ;-) because it's the flexibility of CBOR that allows it.

So what's confusing is that every objective has a value, and (the way I wrote it)
the value of the "AN__join_proxy" is simply named "method". Perhaps I should not
use a short cut in the CDDL; would this be clearer:

  proxy-objective = ["AN_join_proxy", objective-flags, loop-count,
                     objective-value]
  
  objective-flags = ; as in the GRASP specification
  loop-count = 1    ; limit to link-local operation
  objective-value = method
  method = "BRSKI-TCP" / "BRSKI-UDP"

I'll come back separately with my musings about how I understand IPIP to work.

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jul 2017 20:47:35 -0400

Brian E Carpenter <[email-masked]> wrote:
    > 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:

This LL address is the Lr from my email of three minutes ago:

mcr> Instead, I have two suggestions, not entirely mutually exclusive:
mcr>  1) the Registrar says, "I accept IPIP on Address Ar, use Lr for
mcr>  connections"
mcr>  2) we make Lr = well known Link-Local anycast address

I included Lr in the protocol, even if we might decide that we want to make
it well-known.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Jul 2017 14:04:02 +1200

> I included Lr in the protocol, even if we might decide that we want to make

As I just said, I don't understand why this address is even needed.

   Brian