On Wed, May 31, 2017 at 01:59:57PM +1200, Brian E Carpenter wrote:
> > As you indicate, DULL has a whole pile of rules. Why are those rules
> > sufficient?
>
> They are supposed to be self-explanatory. I'm not sure what
> the issue is.
>
> Toerless: please speak up, you wrote that text!
Eric: We just tried to minimize any insecure usage of GRASP that we MUST do and
then very explicitly
enumerate the constraints in the protocol that must be observed to minimize the
security impact.
Logically speaking, all we need to do insecurely is to subnet-multicast
"My IP-address is FOO and i can do BAR", so that neighbors on the subnet that
want to do BAR
can discover FOO. And then that neighbor will create a standard secure
connection, eg: TLS
to FOO.
To the best of my knowledge, there is no logical way to further reduce the
insecure
part of communications unless you do know upfront the IP-address of all the
neighbors
we should BAR with, and we do not know those addresses.
So, the whole discussion then ended up how to really constrain the operations
of a protocol
such as GRASP that is used in multiple contexts such that there is no leakage
between
one (eg: insecure) context and another (insecure or secure) context. Thats what
all the
rules are for. I think we have gone far beyond what i have seen elsewhere in
really constraining
the protocol operations for an insecure context in this fashion. In man other
cases such rules
where counterfitted long after the fact.
We had long debates about how to do this most securely, comparing mDNS and
GRASP etc. pp.
Even down to the points raised of "we want to reuse existing protocol to reduce
code-space
requirements" vs. "we want to use a unique protocol for the insecure context to
minimize
leakage opportunity". Ultimately for me the argument won: "we want to use our
own protocol to
maximize the security rules because prior protocols have done a sh**y job".
Alas, as usual in IETF documents, 90% of the reasoning behind all this can
never make it
into documents because the mayority of overworked reviewers really hate large
amounts of
text (for a reason *sigh*).
How else can i help on this point ? If my explanation answers your question but
you feel
there shold be some level of this in the GRASP text, then it would be great if
you could
suggest that in your own words!
[Will reply to the other points separately.]
Cheers
Toerless
>
> >> and how you bridge multicast to unicast.
> >>
> >> ? We don't do that.
> >>
> >
> > Huh? You send out a discovery packet in multicast and then expect
> > someone to connect to you via unicast, no?
>
> Yes, but that is elsewhere in the document (I think that came up
> in Alissa's comments). Nothing new to say in this part.
>
> >
> >
> >>> That is the trust model, but really as an explanatory matter I think
> >>>> it belongs in draft-ietf-anima-reference-model rather than here.
> >>>> I will add a few words in the High Level Deployment Model
> >>>> section and/or the Security Considerations.
> >>>>
> >>>> What we do say already is that authorization of ASAs is out of scope.
> >>>> I am certain that it needs to be tackled, but not here.
> >>>>
> >>>
> >>> I don't see how you have a complete protocol without that.
> >>
> >> The starting position is that we trust all autonomic nodes and therefore
> >> the ASAs installed in them. We are in the context of a single operator
> >
> > so this isn't really a stretch.
> >
> >
> > I certainly can see how someone might decide to deploy a system like
> > this, but it seems pretty problematic to have a system that is so brittle
> > to single-point compromise (The term of art here is "distributed single
> > point of failure")
> >
> >
> >> The questions around life cycle
> >> management of ASAs, which would certainly involve authorization,
> >> were intentionally not in the initial WG charter. I think it's true
> >> that you can't have a complete *system* without that, but I disagree
> >> that it's a requirement for the protocol.
> >>
> >
> > At minimum you need to specify that this is your trust model and
> > then work through the implications of compromise of some subset
> > of nodes, as well as of an attacker who can influence which nodes
> > you talk to.
>
> That really, really belongs in the reference model or the ACP draft;
> it's in no way specific to GRASP, because nodes could use any protocol
> they please over the ACP.
>
> Brian
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
