Re: [Anima] Comments from Alex G. on draft-carpenter-anima-asa-guidelines

[Brian E Carpenter]

On 20/03/2018 23:39, Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) wrote:
> Hi Alex,
> 
> Thanks for your comments on draft-carpenter-anima-asa-guidelines.
> 
> If I get it correctly you raised the following points:
> 
>   1.  -better describe what ASA are: rather application or network service, 
> and better describe the border between the two and implications for ASA 
> designers/developers in the draft.
> 
> I think it is an important (and not so simple) topic and worth being 
> discussed.
> 
> Would welcome views from the group.

Yes, these are aspects that we discussed in NMRG and also in the UCAN BOF and 
early
days of the WG. Probably we have most of the points scattered around in various
documents and meeting minutes, but we need to collect them in one place.

>   1.  -NFV is an important area for future networks, and more focus for ANIMA 
> and ASA should be devoted.
> 
> Agreed; However, I'm not aware that NFV community is following ANIMA work and 
> guidelines on autonomic VNF design/development. Although there are several 
> autonomic/self-* behavior/functionality being developed in NFV.
> 
> There is clearly a gap here, and a difference in approach.

I couldn't find an adequate reference for NFV, which is why the drafts says
[reference needed]. I didn't find a clear definition of "microservices" either,
which is why I didn't use the term.

I think autonomic networking is a new form of network management. Is there
anything wrong with the current statement?
  "For example, the services envisaged for
   network function virtualisation [reference needed] or for service
   function chaining [RFC7665] might be managed by an ASA rather than by
   traditional configuration tools."

An ASA to manage SFC might be an interesting use case to develop.
 
>   1.  -You mentioned something about the decoupling of self-* functionality 
> (self-configuration, self-healing...)
> 
> Not sure I get fully what was your comment on this aspect. Could you clarify 
> / develop?

Again, I think this is a use case issue. The way these self- properties
interact is surely not the same in all cases?

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 (part 4?)

[Michael Richardson]

MAX: please look for your name.

Toerless Eckert  wrote:
> Section 5)

> a) Suggest changing the title to "Protocol Details (Pledge - Registrar
> - MASA / CA)"
> to distinguish from Section 4. Might consider also to move up section

renamed.

> b) MASA URI is "https:// authority "./well-known/est".
> ^
> missing a " ?

already fixed.

> c) BRSKI-EST connections SHOULD use persistent connections
> The intention of this guidance is to ensure the provisional TLS
> authentication occurs only once and is properly managed.

> This is not clear to me, please rephrase.

> - What does "properly managed" mean ?

I no longer recall.
I think it's content-free.  It means don't throw away the connection
each time or do dumb things with your SSL context.

> - Why would provisional TLS authentication have to occur more than once
> without persistent connection ?


  While EST section 3.2 does not insist upon use of HTTP 1.1
  persistent connections, BRSKI-EST connections SHOULD use persistent
  connections.  The intention of this guidance is to ensure the
  provisional TLS state occurs only once, and that the subsequent
  resolution of the provision state is not subject to a MITM attack
  during a critical phase.


> The first connection only retrieves the voucher, but then lets say the
> Pledge closes the connection and builds a new one for EST
> enrollment. On that second one it would not need to do provisional
> authentication. /cacerts after /requestvoucher ?

I agree that it's possible to come up with a number of places in which
one could restart the TLS connection, at which point a MITM would either
be detected, or would cause a failure, but I would rather not open this door.

The pledge would have to remember the server's certificate and make sure that
it always connects to a server with the same (identical) certificate.

If the JRC is implemented in a load-balanced scenario with a front-end
*TCP* (not SSL) proxy that distributes load, then it is possible that it
would be legitimate for the different servers to have different
certificates.  As long as the voucher comes out correct, that's fine.

But, if the pledge is directed to different servers, which a non-persistent
connection could cause to occur, then the pledge will have a hard time.

What if the single server executes a planned reboot, and when it restarts, a
new (fresher) certificate has been installed?The persistent connection
could be tuned to keep server from rebooting until that transaction is over.

Finally, the non-persistent connections could be redirected by the Join Proxy
to different JRCs!

> d)  Q: How would BRSKI work in the absence of persistent connections or
> in the presence of failures ? I guess each request from the pledge is a
> standalone transaction and the pledge would just repeat them until it
> succeeds or until a return code would indicate that the Registrar does
> not support this step and the pledge has to terminate.

The requests from the pledge are not standalone transactions.
They are a series of connections that build towards a result.
I don't think we need to support non-persistent connection.

> Aka: The way i see it, the reason for persistent connections is really
> just
> avoiding unnecessary repeated (expensive) TLS connection setup...

yes.  So, couldn't you have edited your comments then?

> e)  "If the Registrar responds with a redirection to other web origins"

> A reason for this rule should be written into that paragraph.
> ... This is to minimize attacks by fake registrars trying to
> indefinitely redirect a pledge.

MAX: I think that there are other reason as well?
MAX: Also, the pledge can't go anywhere by URL, only to where the Proxy
 directs it, so really can any redirection be accepted?
 Of course, it can do Host:

I have opened ticket: https://github.com/anima-wg/anima-bootstrap/issues/50

> f)  "It should proceed to other discovered Registrars if there are any"

> Pledes don't discover Registrars, the discover Proxies.
> the Proxy can see a couple redundant Registrars.

fixed with:


  To avoid blocking on a single erroneous Registrar the Pledge
  MUST drop the connection after 5 seconds in which there has
  been no progress on the TCP connection.
  It should proceed to
connect to any other Registrar's via any other discovered
Proxies if there are any.  If there were no
other Proxies discovered, the Pledge MAY continue to wait,
as long as it is concurrently listening for new Proxy
announcements.



> f.1) "If necessary the Pledge calls the EST defined /cacerts method to
> obtain the domain owners' CA certificate."

> Please 

[Anima] Comments from Alex G. on draft-carpenter-anima-asa-guidelines

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hi Alex,

Thanks for your comments on draft-carpenter-anima-asa-guidelines.

If I get it correctly you raised the following points:

  1.  -better describe what ASA are: rather application or network service, and 
better describe the border between the two and implications for ASA 
designers/developers in the draft.

I think it is an important (and not so simple) topic and worth being discussed.

Would welcome views from the group.



  1.  -NFV is an important area for future networks, and more focus for ANIMA 
and ASA should be devoted.

Agreed; However, I'm not aware that NFV community is following ANIMA work and 
guidelines on autonomic VNF design/development. Although there are several 
autonomic/self-* behavior/functionality being developed in NFV.

There is clearly a gap here, and a difference in approach.



  1.  -You mentioned something about the decoupling of self-* functionality 
(self-configuration, self-healing...)

Not sure I get fully what was your comment on this aspect. Could you clarify / 
develop?

Thank you.
Best regards, Laurent.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Related work for draft-carpenter-anima-asa-guidelines

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

Sheng you mentioned two works we should liaise to, which could help getting 
deployment experience.
Bing mentioned an ID but I cannot find it under the ANIMA related docs (not 
T2TRG ones).

Could you share the pointers or contacts, please?

Thanks, Laurent.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima