Re: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Miika Komu <[e-mail]>]

Hi Benjamin,

ti, 2020-02-25 kello 11:00 -0800, Benjamin Kaduk kirjoitti:

> > > [...]
> > > Some section-by-section comments follow.
> > > 
> > > Section 2
> > > 
> > >    Responder:
> > >       The Responder is the host that receives the I1 packet from
> > > the
> > >       Initiator.
> > > 
> > > Does this still hold if the message is misdelivered or an
> > > attacker
> > > is in the network?
> > 
> > If misdelivered, the HITs don't match and the receiver host drops
> > the
> > packet as documented in the base exchange specification in RFC7401
> 
> A well-behaved receiver host drops the packet; what if the host is
> under
> the control of an attacker?

let's say the recipient of I1 message is an attacker that does not have
the necessary private key (to generate the same destination HIT as in
the I1 message) but responds with an R1. The initiator receives the R1
and starts processing it:

a) Assuming the attacker just generated a random private + public key,
the source HIT of R1 does not match with destination HIT of I1, and the
Initiator just drops the message. It is worth noting that the Initiator
can also check the public key when it has been configured to it or
obtained from DNS (RFC8005).

b) Assuming the attacker has replayed an R1, this protected by R1
generation counter as documented in 
https://tools.ietf.org/html/rfc7401#section-4.1.4

This not really related to draft-ietf-hip-native-nat-traversal-28 but
the underlying protocol (RFC7401); do you still think something should
be mentioned?

> > > [...]
> > > Section 4.5
> > > 
> > >    In step 2, the Control Relay Server receives the I1
> > > packet.  If
> > > the
> > >    destination HIT belongs to a registered Responder, the Control
> > > Relay
> > >    Server processes the packet.
> > > 
> > > Do HIP participants register specifically as Responder/Initiator,
> > > or
> > > is this just that the entity that is Responder in this exchange,
> > > has
> > > registered at the Control Relay Server?
> > 
> > I think this is common confusion stemming from RFC8003 and  RFC8004
> > :)
> > 
> > Initiator just means the participant sending the I1 of the base
> > exchange, and responder is the participant receiving the I1 and
> > responding with an R1. And there are two base exchanges involved:
> > one
> > during registration and the other one where the actual NAT
> > traversal
> > procedures take place. Perhaps this clarifies the situation:
> > 
> > Base exchange 1: the registration (=base exchange with some extra
> > parameters) you have the following roles:
> > * Control Relay Client = Initiator1
> > * Control Relay Server = Responder1
> > 
> > Base exchange 2: during a base exchange via a HIP relay, the roles
> > are
> > as follows:
> > * Initiator2 = (for example a web browser connecting to a HIT of
> > Responder2)
> > * Control Relay Server = same as above (i.e. HIP message forwarder)
> > * Responder2 = (for example a web server)
> > 
> > (Note that the numbers 1-1 and 2-2 are coupled with each other)
> > 
> > After the second base echange, Initiator2 and Responder2 initiate
> > the
> > NAT traversal procedures with each other.
> > 
> > We have chosen to name the end-hosts just as "Initiator" and
> > "Responder" in this section because the registration is documented
> > in a
> > separate section. The terminology is aligned with RFC7401 but I can
> > understand your confusion :)
> 
> I don't think I'm actually confused, but I'm saying that if we talk
> about a
> "registered Responder", a reasonable reader might infer that there is
> some
> entity that has registered to be a Responder, which is not exactly
> what's
> going on -- there's an entity that has registered, and registration
> is
> needed in order to be a responder when behind a NAT, and it happens
> to be the
> responder this time.  But it is free to be an initiator for other
> exchanges
> without additional registration.

I hope this change resolves the ambiguity:

If the destination HIT belongs to a successfully registered Control
Relay Client (i.e., the host marked "Responder" in Figure 4), the
Control Relay Server processes the packet.

> > > [...]
> > > Section 6.1
> > > 
> > > The RFC 5770 text talks about TURN servers, but that's no longer
> > > applicable in this document (instead, Data Relay Sfrom an Control
> > > Data Server server.ervers are used to
> > > relay data in a similar usage).
> > 
> > fixed:
> > 
> > With such a legacy NAT, the only option left would be to use a
> > relayed
> > transport address from an *Control Relay Server* server.
> 
> The "fixed" version says "Control Relay" but I thought it was going
> to be
> "Data Relay"; you didn't explicitly tell me I was wrong about it, so
> please
> confirm one way or the other...
> 
> Thanks for the updates!

sorry, my bad, of course it should be Data Relay. Double fixed version
will be:

With such a legacy NAT, the only option left would be to use a relayed
transport address from an Data Relay Server.