[Anima] Re: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Michael,

Pleasee see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Michael Richardson <[e-mail]>
> Envoyé : dimanche 6 avril 2025 23:36
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : The IESG <[e-mail]>; draft-ietf-anima-brski-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-
> prm-18: (with DISCUSS and COMMENT)
> 
> 
> 
> Mohamed Boucadair via Datatracker <[e-mail]> wrote:
>     > # Unconditional MUST
> 
>     > CURRENT:
>     > The pledge MUST respond to all requests regardless of the
>     > Host header field provided by the client (i.e., ignore it).
> 
>     > I don’t think that is safe.
> 
> Why?
> 

[Med] Because you make it an absolute requirement to reply independent of any other condition, including the sender behavior. An obvious case to break the MUST here is to no reply to an avalanche of requests from the same sender. Some rate-limit can be provided to the pledge as a basic guard.

We don't need to identify all exceptions, but you can turn all such absolute MUST with something such as "Absent policy otherwise, the pledge MUST respond to all requests ...".

> The Registrar Agent really has *only* the IP address of the
> pledge.
> No virtual hosting is possible.  So, **anything** it puts into the
> Host: header will be wrong.  mDNS may well return IPv6-LL
> addresses.
> 
>     > I’m afraid this needs some scoping; as there are other
> legitimate conditions
>     > where the pledge does not have to reply.
> 
> Like... what?

[Med] See above. Guards again overload/abuse, typically.

> 
>     > # Compliance with HTTP BCP (RFC9205)
> 
>     > CURRENT:
>     > If the pledge is unable to create the PVR, it SHOULD respond
> with an
>     > HTTP error status code to the Registrar-Agent.  The
> following client
>     > error status codes SHOULD be used:
> 
>     > The use of normative language is IMO not compliant with the
> guidance in
>     > RFC9205, about error handling.
> 
> okay, we'll review.

[Med] ACK.

> 
>     > # Cluster with 8366bis
> 
>     > CURRENT:
> 
>     > The JSON PVR Data MUST contain the following fields of the
> “ietf-
>     > voucher-request” YANG module as defined in
>     > [I-D.ietf-anima-rfc8366bis];
> 
>     > I think this spec should be clustered with 8366bis. There
> are several structure
>     > that used in this document and which depends on what is
> defined in 8366bis.
>     > Changes to the bis will have implications on this one.
> 
> Yes, it's all gonna be in a cluster.
> Is there something you think we need to put into the I-D to make
> that so, other than a normative reference, which it already has?

[Med] Given the impact on data serialization, my current take is to not send this document to the RFC editor. I know this is frustrating but this is imposed by the structure and strong dependency of the two anima pieces. 

Even if the document was approved now, it has to wait in MISSREF with a risk to be revisited to reflect changes to the 8366bis.

I did check the bis quickly before making the DISCUSS point. There are signs that might let me think that the work is not stable yet (the yang module does not validate, for example).

> 
>     > With that in mind, I tend to suggest holding approval of
> this specification
>     > till we finalize the bis spec.
> 
> No, because that creates a loop of getting document X done before
> document Y can proceed.  We already, as a WG, said that rfc8366bis
> would wait until all others are done.  RFC8366bis could otherwise
> progress without the others, and when we discover problems that
> require updates to two places, would wind up making us yank it
> back from the RFC-editor.  We went through this with
> RFC8995 already, and the WG learnt it's lesson.

[Med] I appreciate sharing that background. I don't think that we are making a service to ourselves by not prioritization draft-ietf-anima-rfc8366bis given that all theses pieces depend on it:

* draft-ietf-anima-brski-cloud 	Proposed Standard	normatively references	
* draft-ietf-anima-brski-prm	BRSKI Proposed Standard	normatively references	
* draft-ietf-anima-constrained-join-proxy	Proposed Standard	normatively references	
* draft-ietf-anima-constrained-voucher	Proposed Standard	normatively references	
* draft-ietf-anima-jws-voucher	Proposed Standard	normatively references

Let's think about how to better streamline things here.

> 
>     > # Requires TLS1.3
> 
>     > CURRENT:
>     > As already stated in [RFC8995], the use of TLS 1.3 (or
> newer) is
>     > encouraged.  TLS 1.2 or newer is REQUIRED on the Registrar-
> Agent
>     > side.  TLS 1.3 (or newer) SHOULD be available on the
> registrar, but
>     > TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be available
> on the
>     > MASA, but TLS 1.2 MAY be used.
> 
>     > Please update to take into to reflect draft-ietf-uta-
> require-tls13.
> 
> The reality that many platforms do not have FIPS-140 appproved TLS
> 1.3
> stacks remains true.   It's getting better, but it's just not
> there yet.
> 

[Med] May be add a note to explain the current approach in the draft. Interesting to see that you are scheduled in the same telechat as that UTA spec :-) 

> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.