On Thu, Apr 06, 2017 at 05:22:48PM -0400, Michael Richardson wrote:
>     > Is this actually stated anywhere in RFC2460 ? I could not find
>     > it. RFC7045 says:
> 
> Yes, unclearly.  Subject to rfc2460bis being returned to the 6man WG to make
> sure that the text is clearer.

(P)roblem (o)f (o)ther (p)eople ;-)

>     > Unless RPL for the ACP or any future ACP mechanism do require reception 
> and processing
>     > of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 
> packet targeted
>     > to their ACP address.
> 
> That's not enough. An attacker could just send frames at the router
> targetting an ACP address via a normal port.
> 
> It's that the ACP routers should run the ACP in a VRF, and SHOULD NOT
> exchange traffic with other VRFs, including "The Internet"

Puuh... first you sneak in the RPL finger, now you want me to give you the whole
security arm... sure ;-). How about this:

To maintain the desired traffic isolation of the ACP, the VRF used for the ACP 
MUST be
set up so that no traffic can be exchanged with other VRF.  Configuration in 
other VRFs
(such as extranet route configuration) must not allow to change this.

>     > When using the default ACP profile of RPL in the ACP (see section 
> ....), IPv6-in-IPv6
>     > encapsulation is not required by RPL.
> 
> So, we are going to run in storing mode, so we never need RH3 headers.
> If all senders (including nodes in the NOC which do not speak ACP...) include
> RPI headers (which is used for loop-detection), then all is well. Otherwise,
> we have to insert RPI HbH headers, which requires an IPIP header.

Hmm.. in the implementations i have seen, i do not think RPI headers where used
by senders. And that seemed to be working fine. Is it a MUST ? If so which 
section/rfc ?

>     > When reception/processing of IPv6-in-IPv6 packets is required for RPL, 
> only
>     > IPv6-in-IPv6 packets with an ACP address from the same autonomic domain 
> should be
>     > accepted.
> 
> yes.
> 
>     > If the ACP can not trust an ASA to not behave malicious or to be 
> disruptive malfunctioning
>     > traffic from an ASA into the ACP should be filtered such that only 
> known necessary traffic
>     > for that ASA should be permitted into the ACP.
> 
>     > - I hope that pointing to your draft and the paragraphs about "ASAs 
> behaving badly"
>     > is sufficient to score ACP the "good neighbor" medal. If not, i welcome 
> any additional
>     > suggestions.
> 
> Yes, I think so.

Thanks!
    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    
> [
> 
> 
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
[email protected]

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to