Hi Benjamin,
ke, 2020-07-15 kello 18:32 -0700, Benjamin Kaduk via Datatracker
kirjoitti:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-31: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>
>
>
> ---
> ---
> COMMENT:
> ---
> ---
>
> Thanks for addressing the potential "cross-message" attack on the
> HMAC
> contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay
> Server
> from offering the rendezvous services.
I actually wasn't so happy with my original coarse-grained solution for
cross-message attacks, so I wrote a more fine-grained one. My reasoning
is that I think reserving one public IP for RVS and another one for
Relay is maybe too much. So, the solution in draft-ietf-hip-native-nat-
traversal-32 is as follows (in a nutshell):
* Relay server can offer both RVS and Relay service but allows the
client to pick only one.
* The server sends a registration error (new IANA type) if client tries
to picks the two services.
I also included some reasoning for the security mechanism. To avoid
bloating the existing section, I moved all text regarding to the cross-
message attack under Security Considerations in section 6.8. Cross-
Protocol Attacks:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-32#section-6.8
> I think in order for the
> protection against the attack to be complete, though, we need to say
> that a HIP peer attempting to reach a Control Relay Server MUST
> reject
> any messages appearing to originate from that server, that contain an
> RVS_HMAC parameter. That is, the current text will keep honest
> actors
> from generating the bad situation, but we also want to protect
> ourselves
> against accepting input from a bad actor attempting to cause the bad
> situation.
I added text regarding to your bad "bad actor" suggestion. This
required also a new notify type to that the client will send when it
receives RVS_HMAC in the wrong context. This text is also in section
6.8.
> Thank you as well for addressing all of my other comments on the -30.
> They seem generally satisfactory, and my apologies for not responding
> to
> them sooner.
no worries, thanks for the very detailed review!
> I just have two remaining remarks:
>
> Section 1
>
>tunneling overhead). Another solution is specified in [RFC5770],
>which will be referred to "Legacy ICE-HIP" in this document. The
>
> nit: s/to/to as/
thanks, fixed
> Section 4.6.2
>
>[RFC7401] section 5.3.5 states that UPDATE packets have to include
>either a SEQ or ACK parameter (but can include both). According
> to
>the RFC, each SEQ parameter should be acknowledged separately. In
>
> I don't see anything to support "acknowledged separately"; on the
> contrary, I see "A host MAY choose to acknowledge more than one
> UPDATE
> packet at a time; e.g., the ACK parameter may contain the last two
> SEQ
> values received, for resilience against packet loss." Perhaps the
> intent was "each SEQ parameter needs to be explicitly acknowledged"?
"...in the context of this document" - good catch. I revised the text
as follows:
In the connectivity check procedure specified in Section 4.6.1, each
SEQ parameter should be acknowledged separately.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
