On 8/5/2016 9:40 PM, David Mazieres wrote:
> ...
> Also, following the previous discussion, I've looked over the "SHOULDs"
> in the document, and many of them are not followed by an explicit
> exception. Let me group them here to get your feedback about whether
> this is a problem, and whether I need to be more specific in the
> document. Here's a list of types of SHOULD that are not immediately
> followed by an exception:
>
> * Many of the uses concern APIs that implementations SHOULD provide.
> The reason for the SHOULD is that in some cases this may be impossible
> or inapplicable. For example, if you are implementing TCP-ENO inside
> a dedicated NAS server, there might not be the same notion of
> applications giving API commands. On the other hand, these points are
> pretty important to the success of TCP-ENO, and should be followed in
> the vast majority of cases.
The problem with SHOULD for APIs is that users then can't rely on any of
those features. So the real question is:
- what are the API features that are absolutely required
- why are you listing any that are optional?
For APIs, the second set ought to be optimizations, not features or
capabilities IMO.
> * "TEP specifications SHOULD refer to hosts A and B to specify
> asymmetric behavior." Again, no explicit exemption, but the point is
> that there might be a TEP that is not asymmetric, or where some other
> optimization makes it better to specify hosts by the numeric order of
> their Diffie-Hellman parameters or something. I suppose I could
> change that to a MAY, but if TEPs talk about active/passive openers,
> that could mess up simultaneous open.
Are you saying it's better to be symmetric? If so, why?
If not, are you saying that it's more typical that TEPs will be
symmetric? In that case, you shouldn't be using 2119 keywords.
> * Implementations SHOULD provide forward secrecy. The important point
> is that the TEPs MUST be amenable to forward secrecy.
That MUST turns the SHOULD into a MUST too.
> We didn't say
> MUST for the implementation because that may not always be
> possible--e.g., implementation considerations may someday require
> keying material to be shared across servers or with a load-balancer or
> something. We don't want to say you can't implement TCP-ENO under
> such circumstances, but we want people to think long and hard about
> the implications for confidentiality.
That consideration is too vague to weaken a MUST into a SHOULD, IMO.
Why not "MUST provide forward secrecy" and indicate that any future
sharing is viable only when it preserves forward secrecy?
> * Applications SHOULD authenticate endpoints, SHOULD treat session IDs
> monolithically, SHOULD use the application aware bit. Again, these
> are all obviously very good things. But there are so many different
> things an application can do, and so many constraints applications can
> be subject to, that it seems inappropriate for a transport-layer
> document to use MUST in regards to applications. Anyway, we can't
> enforce what applications will do.
If you say SHOULD, you need to indicate the conditions under which apps
would do otherwise.
Simply saying "we don't know what they want" isn't enough - you're
providing a framework and app choices have implications in the
capabilities provided.
E.g., authenticating endpoints kills BTNS-style PKI-free use - but it's
very clear that if you drop authentication, you're allowing MITM attacks
but also raising the bar against off-path attacks.
> * Applications SHOULD migrate to option TBD from the ExID. RFC7413 used
> the word SHOULD for exactly the same point in its IANA considerations
> section, so we just copied what those authors did. The TCP-ENO team
> is clearly not well versed in the practice of allocating and
> specifying TCP option kind numbers, so we are happy to follow any
> specific guidance from the working group on whether to change that
> SHOULD to a MUST.
MUST serves to deprecate ExID use faster. IMO, you should say MUST
initiate using the new option and MAY continue to support the ExID for
compatibility with development implementations.
If you change the protocol so those development variants aren't
something you want to continue to deal with, then just say MUST and move on.
There's nothing technically wrong with the SHOULD text in RFC7413, but
it shot themselves in the foot IMO by requiring continued legacy support.
> * TEPs SHOULD compute session IDs using only well-studied and
> conservative hash functions. Here the problem is that the terms
> well-studied and conservative are subjective. So while I think it's
> an important point people need to worry about violating, the point is
> also nebulous enough that I don't see how to enforce it with a MUST.
> Put another way, the hash functions SHOULD be as conservative as
> practical, with an implicit exception where more conservative hash
> functions are not practical.
If there is no objective definition of the requirement, then you really
have no business stating it.
Just talk about what constitutes a good hash functions, even
subjectively. Leave requirements to objective conditions.
> * We say the non-SYN-form ENO option SHOULD be 0 bytes if not otherwise
> specified by the TEP, but I'll change that to a MUST in the next
> draft, since it doesn't matter anyway.
I would encourage you to be relatively explicit in what the sender
should do. Leaving it vague complicates receiver processing.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
