Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

I do not have time to assess this claim. I would encourage the security ADs
to do so.

On Fri, Feb 21, 2020 at 6:36 AM Miika Komu  wrote:

> Hi Eric,
>
> so your original question was:
>
> "The concern is what's known as a "cross-protocol" attack. Is there
> any situation in which there might be ambiguity about two message
> types that are protected with the same key?"
>
> No ambiguity about the message types, because the messages between
> relay client and relay server carry always either a RELAY_FROM or
> RELAY_TO parameter (depending on direction) and this is covered by the
> HMAC.
>
> In the rendezvous case, you have different FROM and VIA_RVS parameters,
> also covered by HMACs.
>
> pe, 2020-02-21 kello 05:34 -0800, Eric Rescorla kirjoitti:
> > Typically in security protocols we look for demonstrations of this.
> > What is your argument for why it cannot?
> >
> > -Ekr
> >
> >
> > On Fri, Feb 21, 2020 at 4:25 AM Miika Komu 
> > wrote:
> > > Hi,
> > >
> > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> > > >
> > > >
> > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <
> > > miika.k...@ericsson.com>
> > > > wrote:
> > > > > Hi Eric,
> > > > >
> > > > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > > > miika.k...@ericsson.com>
> > > > > > wrote:
> > > > > > > Hi Eric,
> > > > > > >
> > > > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > > > S 5.8.
> > > > > > > > > > > >>
> > > > > > > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > > > > > > >>
> > > > > > > > > > > >>   As specified in Legacy ICE-HIP [RFC5770],
> > > the
> > > > > > > > > RELAY_HMAC
> > > > > > > > > > > parameter
> > > > > > > > > > > >>   value has the TLV type 65520.  It has the
> > > same
> > > > > > > > > semantics
> > > > > > > > > > > as RVS_HMAC
> > > > > > > > > > > >>   [RFC8004].
> > > > > > > > > > > >
> > > > > > > > > > > > What key is used for the HMAC?
> > > > > > > > > > >
> > > > > > > > > > > clarified this as follows:
> > > > > > > > > > >
> > > > > > > > > > > [..] It has the same semantics as RVS_HMAC as
> > > specified
> > > > > in
> > > > > > > > > section
> > > > > > > > > > > 4.2.1
> > > > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > > > RELAY_HMAC
> > > > > > > is
> > > > > > > > > is
> > > > > > > > > > > keyed
> > > > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > > > specified
> > > > > > > in
> > > > > > > > > > > section 6.5
> > > > > > > > > > > in [RFC7401]), established during the relay
> > > > > registration
> > > > > > > > > procedure
> > > > > > > > > > > as
> > > > > > > > > > > described in Section 4.1.
> > > > > > > > > >
> > > > > > > > > > This seems like it might have potential for cross-
> > > > > protocol
> > > > > > > > > attacks on
> > > > > > > > > > the key. Why
> > > > > > > > > > is this OK>
> > > > > > > > >
> > > > > > > > > this is standard way of deriving keys in HIP. The
> > > keying
> > > > > > > procedure
> > > > > > > > > is
> > > > > > > > > the same as with specified in RFC8004. If there is some
> > > > > attack
> > > > > > > > > scenario, please describe it in detail?
> > > > > > > > > Or is there some editorial issue here?
> > > > > > > >
> > > > > > > > I'm not sure. When I read this text it appears to say
> > > that
> > > > > you
> > > > > > > should
> > > > > > > > be using the same key for two kinds of messages. Is that
> > > > > correct?
> > > > > > >
> > > > > > > the key is always specific to a Host Association, i.e.,
> > > unique
> > > > > > > between
> > > > > > > a Relay Client and a Relay Server. So if there is a
> > > Rendezvous
> > > > > > > server
> > > > > > > (used with RVS_HMAC), this would be a different host and
> > > > > different
> > > > > > > Host
> > > > > > > Association. If the same host provides both rendezvous and
> > > > > relay
> > > > > > > service, it should be fine to reuse the same key.
> > > > > >
> > > > > > Why is that OK? Generally we try not to do this. Do you have
> > > a
> > > > > proof
> > > > > > that it is not possible to have one message mistaken for
> > > another?
> > > > >
> > > > > so I assume we are talking about the (artificial) case where a
> > > > > single
> > > > > host provides both Relay and Rendezvous service, and is
> > > > > communicating
> > > > > with a single registered Client? It's the same control channel,
> > > so
> > > > > I
> > > > > don't see any need to have different HMAC keys for different
> > > > > messages
> > > > > since it's still the same two hosts. Or maybe I misunderstood
> > > your
> > > > > scenario, so please elaborate?
> > > >
> > > > The concern is what's known as a "cross-protocol" attack. Is
> > > there
> > > > any situation in which there might be ambiguity about two message
> > > > types that are protected with the same key?
> > >
> > > I don't see any case where this could 

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Eric,

so your original question was:

"The concern is what's known as a "cross-protocol" attack. Is there
any situation in which there might be ambiguity about two message
types that are protected with the same key?"

No ambiguity about the message types, because the messages between
relay client and relay server carry always either a RELAY_FROM or
RELAY_TO parameter (depending on direction) and this is covered by the
HMAC.

In the rendezvous case, you have different FROM and VIA_RVS parameters,
also covered by HMACs.

pe, 2020-02-21 kello 05:34 -0800, Eric Rescorla kirjoitti:
> Typically in security protocols we look for demonstrations of this.
> What is your argument for why it cannot?
> 
> -Ekr
> 
> 
> On Fri, Feb 21, 2020 at 4:25 AM Miika Komu 
> wrote:
> > Hi,
> > 
> > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> > > 
> > > 
> > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <
> > miika.k...@ericsson.com>
> > > wrote:
> > > > Hi Eric,
> > > > 
> > > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > > > 
> > > > > 
> > > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > > miika.k...@ericsson.com>
> > > > > wrote:
> > > > > > Hi Eric,
> > > > > > 
> > > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > > S 5.8.
> > > > > > > > > > >>
> > > > > > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > > > > > >>
> > > > > > > > > > >>   As specified in Legacy ICE-HIP [RFC5770],
> > the
> > > > > > > > RELAY_HMAC
> > > > > > > > > > parameter
> > > > > > > > > > >>   value has the TLV type 65520.  It has the
> > same
> > > > > > > > semantics
> > > > > > > > > > as RVS_HMAC
> > > > > > > > > > >>   [RFC8004].
> > > > > > > > > > > 
> > > > > > > > > > > What key is used for the HMAC?
> > > > > > > > > > 
> > > > > > > > > > clarified this as follows:
> > > > > > > > > > 
> > > > > > > > > > [..] It has the same semantics as RVS_HMAC as
> > specified
> > > > in
> > > > > > > > section
> > > > > > > > > > 4.2.1 
> > > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > > RELAY_HMAC
> > > > > > is
> > > > > > > > is
> > > > > > > > > > keyed 
> > > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > > specified
> > > > > > in
> > > > > > > > > > section 6.5 
> > > > > > > > > > in [RFC7401]), established during the relay
> > > > registration
> > > > > > > > procedure
> > > > > > > > > > as 
> > > > > > > > > > described in Section 4.1.
> > > > > > > > > 
> > > > > > > > > This seems like it might have potential for cross-
> > > > protocol
> > > > > > > > attacks on
> > > > > > > > > the key. Why
> > > > > > > > > is this OK>
> > > > > > > > 
> > > > > > > > this is standard way of deriving keys in HIP. The
> > keying
> > > > > > procedure
> > > > > > > > is
> > > > > > > > the same as with specified in RFC8004. If there is some
> > > > attack
> > > > > > > > scenario, please describe it in detail?
> > > > > > > > Or is there some editorial issue here?
> > > > > > > 
> > > > > > > I'm not sure. When I read this text it appears to say
> > that
> > > > you
> > > > > > should
> > > > > > > be using the same key for two kinds of messages. Is that
> > > > correct?
> > > > > > 
> > > > > > the key is always specific to a Host Association, i.e.,
> > unique
> > > > > > between
> > > > > > a Relay Client and a Relay Server. So if there is a
> > Rendezvous
> > > > > > server
> > > > > > (used with RVS_HMAC), this would be a different host and
> > > > different
> > > > > > Host
> > > > > > Association. If the same host provides both rendezvous and
> > > > relay
> > > > > > service, it should be fine to reuse the same key.
> > > > > 
> > > > > Why is that OK? Generally we try not to do this. Do you have
> > a
> > > > proof
> > > > > that it is not possible to have one message mistaken for
> > another?
> > > > 
> > > > so I assume we are talking about the (artificial) case where a
> > > > single
> > > > host provides both Relay and Rendezvous service, and is
> > > > communicating
> > > > with a single registered Client? It's the same control channel,
> > so
> > > > I
> > > > don't see any need to have different HMAC keys for different
> > > > messages
> > > > since it's still the same two hosts. Or maybe I misunderstood
> > your
> > > > scenario, so please elaborate?
> > > 
> > > The concern is what's known as a "cross-protocol" attack. Is
> > there
> > > any situation in which there might be ambiguity about two message
> > > types that are protected with the same key?
> > 
> > I don't see any case where this could occur.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

Typically in security protocols we look for demonstrations of this. What is
your argument for why it cannot?

-Ekr


On Fri, Feb 21, 2020 at 4:25 AM Miika Komu  wrote:

> Hi,
>
> to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> >
> >
> > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu 
> > wrote:
> > > Hi Eric,
> > >
> > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > >
> > > >
> > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > miika.k...@ericsson.com>
> > > > wrote:
> > > > > Hi Eric,
> > > > >
> > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > S 5.8.
> > > > > > > > > >>
> > > > > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > > > > >>
> > > > > > > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > > > > > > RELAY_HMAC
> > > > > > > > > parameter
> > > > > > > > > >>   value has the TLV type 65520.  It has the same
> > > > > > > semantics
> > > > > > > > > as RVS_HMAC
> > > > > > > > > >>   [RFC8004].
> > > > > > > > > >
> > > > > > > > > > What key is used for the HMAC?
> > > > > > > > >
> > > > > > > > > clarified this as follows:
> > > > > > > > >
> > > > > > > > > [..] It has the same semantics as RVS_HMAC as specified
> > > in
> > > > > > > section
> > > > > > > > > 4.2.1
> > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > RELAY_HMAC
> > > > > is
> > > > > > > is
> > > > > > > > > keyed
> > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > specified
> > > > > in
> > > > > > > > > section 6.5
> > > > > > > > > in [RFC7401]), established during the relay
> > > registration
> > > > > > > procedure
> > > > > > > > > as
> > > > > > > > > described in Section 4.1.
> > > > > > > >
> > > > > > > > This seems like it might have potential for cross-
> > > protocol
> > > > > > > attacks on
> > > > > > > > the key. Why
> > > > > > > > is this OK>
> > > > > > >
> > > > > > > this is standard way of deriving keys in HIP. The keying
> > > > > procedure
> > > > > > > is
> > > > > > > the same as with specified in RFC8004. If there is some
> > > attack
> > > > > > > scenario, please describe it in detail?
> > > > > > > Or is there some editorial issue here?
> > > > > >
> > > > > > I'm not sure. When I read this text it appears to say that
> > > you
> > > > > should
> > > > > > be using the same key for two kinds of messages. Is that
> > > correct?
> > > > >
> > > > > the key is always specific to a Host Association, i.e., unique
> > > > > between
> > > > > a Relay Client and a Relay Server. So if there is a Rendezvous
> > > > > server
> > > > > (used with RVS_HMAC), this would be a different host and
> > > different
> > > > > Host
> > > > > Association. If the same host provides both rendezvous and
> > > relay
> > > > > service, it should be fine to reuse the same key.
> > > >
> > > > Why is that OK? Generally we try not to do this. Do you have a
> > > proof
> > > > that it is not possible to have one message mistaken for another?
> > >
> > > so I assume we are talking about the (artificial) case where a
> > > single
> > > host provides both Relay and Rendezvous service, and is
> > > communicating
> > > with a single registered Client? It's the same control channel, so
> > > I
> > > don't see any need to have different HMAC keys for different
> > > messages
> > > since it's still the same two hosts. Or maybe I misunderstood your
> > > scenario, so please elaborate?
> >
> > The concern is what's known as a "cross-protocol" attack. Is there
> > any situation in which there might be ambiguity about two message
> > types that are protected with the same key?
>
> I don't see any case where this could occur.
>
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi,

to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> 
> 
> On Thu, Feb 20, 2020 at 7:38 AM Miika Komu 
> wrote:
> > Hi Eric,
> > 
> > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > 
> > > 
> > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > miika.k...@ericsson.com>
> > > wrote:
> > > > Hi Eric,
> > > > 
> > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > S 5.8.
> > > > > > > > >>
> > > > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > > > >>
> > > > > > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > > > > > RELAY_HMAC
> > > > > > > > parameter
> > > > > > > > >>   value has the TLV type 65520.  It has the same
> > > > > > semantics
> > > > > > > > as RVS_HMAC
> > > > > > > > >>   [RFC8004].
> > > > > > > > > 
> > > > > > > > > What key is used for the HMAC?
> > > > > > > > 
> > > > > > > > clarified this as follows:
> > > > > > > > 
> > > > > > > > [..] It has the same semantics as RVS_HMAC as specified
> > in
> > > > > > section
> > > > > > > > 4.2.1 
> > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > RELAY_HMAC
> > > > is
> > > > > > is
> > > > > > > > keyed 
> > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > specified
> > > > in
> > > > > > > > section 6.5 
> > > > > > > > in [RFC7401]), established during the relay
> > registration
> > > > > > procedure
> > > > > > > > as 
> > > > > > > > described in Section 4.1.
> > > > > > > 
> > > > > > > This seems like it might have potential for cross-
> > protocol
> > > > > > attacks on
> > > > > > > the key. Why
> > > > > > > is this OK>
> > > > > > 
> > > > > > this is standard way of deriving keys in HIP. The keying
> > > > procedure
> > > > > > is
> > > > > > the same as with specified in RFC8004. If there is some
> > attack
> > > > > > scenario, please describe it in detail?
> > > > > > Or is there some editorial issue here?
> > > > > 
> > > > > I'm not sure. When I read this text it appears to say that
> > you
> > > > should
> > > > > be using the same key for two kinds of messages. Is that
> > correct?
> > > > 
> > > > the key is always specific to a Host Association, i.e., unique
> > > > between
> > > > a Relay Client and a Relay Server. So if there is a Rendezvous
> > > > server
> > > > (used with RVS_HMAC), this would be a different host and
> > different
> > > > Host
> > > > Association. If the same host provides both rendezvous and
> > relay
> > > > service, it should be fine to reuse the same key.
> > > 
> > > Why is that OK? Generally we try not to do this. Do you have a
> > proof
> > > that it is not possible to have one message mistaken for another?
> > 
> > so I assume we are talking about the (artificial) case where a
> > single
> > host provides both Relay and Rendezvous service, and is
> > communicating
> > with a single registered Client? It's the same control channel, so
> > I
> > don't see any need to have different HMAC keys for different
> > messages
> > since it's still the same two hosts. Or maybe I misunderstood your
> > scenario, so please elaborate?
> 
> The concern is what's known as a "cross-protocol" attack. Is there
> any situation in which there might be ambiguity about two message
> types that are protected with the same key?

I don't see any case where this could occur.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Thu, Feb 20, 2020 at 7:38 AM Miika Komu  wrote:

> Hi Eric,
>
> to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> >
> >
> > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu 
> > wrote:
> > > Hi Eric,
> > >
> > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > S 5.8.
> > > > > > > >>
> > > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > > >>
> > > > > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > > > > RELAY_HMAC
> > > > > > > parameter
> > > > > > > >>   value has the TLV type 65520.  It has the same
> > > > > semantics
> > > > > > > as RVS_HMAC
> > > > > > > >>   [RFC8004].
> > > > > > > >
> > > > > > > > What key is used for the HMAC?
> > > > > > >
> > > > > > > clarified this as follows:
> > > > > > >
> > > > > > > [..] It has the same semantics as RVS_HMAC as specified in
> > > > > section
> > > > > > > 4.2.1
> > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC
> > > is
> > > > > is
> > > > > > > keyed
> > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as specified
> > > in
> > > > > > > section 6.5
> > > > > > > in [RFC7401]), established during the relay registration
> > > > > procedure
> > > > > > > as
> > > > > > > described in Section 4.1.
> > > > > >
> > > > > > This seems like it might have potential for cross-protocol
> > > > > attacks on
> > > > > > the key. Why
> > > > > > is this OK>
> > > > >
> > > > > this is standard way of deriving keys in HIP. The keying
> > > procedure
> > > > > is
> > > > > the same as with specified in RFC8004. If there is some attack
> > > > > scenario, please describe it in detail?
> > > > > Or is there some editorial issue here?
> > > >
> > > > I'm not sure. When I read this text it appears to say that you
> > > should
> > > > be using the same key for two kinds of messages. Is that correct?
> > >
> > > the key is always specific to a Host Association, i.e., unique
> > > between
> > > a Relay Client and a Relay Server. So if there is a Rendezvous
> > > server
> > > (used with RVS_HMAC), this would be a different host and different
> > > Host
> > > Association. If the same host provides both rendezvous and relay
> > > service, it should be fine to reuse the same key.
> >
> > Why is that OK? Generally we try not to do this. Do you have a proof
> > that it is not possible to have one message mistaken for another?
>
> so I assume we are talking about the (artificial) case where a single
> host provides both Relay and Rendezvous service, and is communicating
> with a single registered Client? It's the same control channel, so I
> don't see any need to have different HMAC keys for different messages
> since it's still the same two hosts. Or maybe I misunderstood your
> scenario, so please elaborate?
>

The concern is what's known as a "cross-protocol" attack. Is there any
situation in which there might be ambiguity about two message types that
are protected with the same key?

-Ekr
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Eric,

to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> 
> 
> On Wed, Feb 19, 2020 at 10:50 PM Miika Komu 
> wrote:
> > Hi Eric,
> > 
> > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > S 5.8.
> > > > > > >>
> > > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > > >>
> > > > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > > > RELAY_HMAC
> > > > > > parameter
> > > > > > >>   value has the TLV type 65520.  It has the same
> > > > semantics
> > > > > > as RVS_HMAC
> > > > > > >>   [RFC8004].
> > > > > > > 
> > > > > > > What key is used for the HMAC?
> > > > > > 
> > > > > > clarified this as follows:
> > > > > > 
> > > > > > [..] It has the same semantics as RVS_HMAC as specified in
> > > > section
> > > > > > 4.2.1 
> > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC
> > is
> > > > is
> > > > > > keyed 
> > > > > > with the HIP integrity key (HIP-lg or HIP-gl as specified
> > in
> > > > > > section 6.5 
> > > > > > in [RFC7401]), established during the relay registration
> > > > procedure
> > > > > > as 
> > > > > > described in Section 4.1.
> > > > > 
> > > > > This seems like it might have potential for cross-protocol
> > > > attacks on
> > > > > the key. Why
> > > > > is this OK>
> > > > 
> > > > this is standard way of deriving keys in HIP. The keying
> > procedure
> > > > is
> > > > the same as with specified in RFC8004. If there is some attack
> > > > scenario, please describe it in detail?
> > > > Or is there some editorial issue here?
> > > 
> > > I'm not sure. When I read this text it appears to say that you
> > should
> > > be using the same key for two kinds of messages. Is that correct?
> > 
> > the key is always specific to a Host Association, i.e., unique
> > between
> > a Relay Client and a Relay Server. So if there is a Rendezvous
> > server
> > (used with RVS_HMAC), this would be a different host and different
> > Host
> > Association. If the same host provides both rendezvous and relay
> > service, it should be fine to reuse the same key.
> 
> Why is that OK? Generally we try not to do this. Do you have a proof
> that it is not possible to have one message mistaken for another?

so I assume we are talking about the (artificial) case where a single
host provides both Relay and Rendezvous service, and is communicating
with a single registered Client? It's the same control channel, so I
don't see any need to have different HMAC keys for different messages
since it's still the same two hosts. Or maybe I misunderstood your
scenario, so please elaborate?
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Wed, Feb 19, 2020 at 10:50 PM Miika Komu  wrote:

> Hi Eric,
>
> ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > S 5.8.
> > > > > >>
> > > > > >>5.8.  RELAY_HMAC Parameter
> > > > > >>
> > > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > > RELAY_HMAC
> > > > > parameter
> > > > > >>   value has the TLV type 65520.  It has the same
> > > semantics
> > > > > as RVS_HMAC
> > > > > >>   [RFC8004].
> > > > > >
> > > > > > What key is used for the HMAC?
> > > > >
> > > > > clarified this as follows:
> > > > >
> > > > > [..] It has the same semantics as RVS_HMAC as specified in
> > > section
> > > > > 4.2.1
> > > > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is
> > > is
> > > > > keyed
> > > > > with the HIP integrity key (HIP-lg or HIP-gl as specified in
> > > > > section 6.5
> > > > > in [RFC7401]), established during the relay registration
> > > procedure
> > > > > as
> > > > > described in Section 4.1.
> > > >
> > > > This seems like it might have potential for cross-protocol
> > > attacks on
> > > > the key. Why
> > > > is this OK>
> > >
> > > this is standard way of deriving keys in HIP. The keying procedure
> > > is
> > > the same as with specified in RFC8004. If there is some attack
> > > scenario, please describe it in detail?
> > > Or is there some editorial issue here?
> >
> > I'm not sure. When I read this text it appears to say that you should
> > be using the same key for two kinds of messages. Is that correct?
>
> the key is always specific to a Host Association, i.e., unique between
> a Relay Client and a Relay Server. So if there is a Rendezvous server
> (used with RVS_HMAC), this would be a different host and different Host
> Association. If the same host provides both rendezvous and relay
> service, it should be fine to reuse the same key.
>

Why is that OK? Generally we try not to do this. Do you have a proof that
it is not possible to have one message mistaken for another?

-Ekr
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Gonzalo Camarillo]

Thanks for the quick response, Eric R!

Eric V, could you please let Miika know how do you want to proceed?

For background, this is the status of the ballot for this draft:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ballot/

Thanks,

Gonzalo

From: Eric Rescorla 
Sent: Wednesday, February 19, 2020 23:21
To: Miika Komu 
Cc: draft-ietf-hip-native-nat-traver...@ietf.org; hip-cha...@ietf.org; 
i...@ietf.org; Gonzalo Camarillo ; 
hipsec@ietf.org
Subject: Re: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: 
(with DISCUSS and COMMENT)

I am no longer an area director, so generally I  suggest you take up these 
comments with the current ADs.

On Wed, Feb 19, 2020 at 1:08 PM Miika Komu 
mailto:miika.k...@ericsson.com>> wrote:
Hi Eric,

thanks for your comments, my response below.

ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
>
>
> On Wed, Nov 7, 2018 at 1:37 PM Miika Komu 
> mailto:miika.k...@ericsson.com>>
> wrote:
> > Hi Eric,
> >
> > apologies for the belated response, I am not working on HIP
> > anymore, so
> > it has been rather difficult to find time for this.
> >
> > On 5/4/18 22:34, Eric Rescorla wrote:
> > > Eric Rescorla has entered the following ballot position for
> > > draft-ietf-hip-native-nat-traversal-28: Discuss
> > >
> > > 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/
> > >
> > >
> > >
> > > ---
> > ---
> > > DISCUSS:
> > > ---
> > ---
> > >
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> > >
> > >
> > > I am very familiar with ICE and yet I found this document
> > extremely
> > > hard to follow. The problem is that it cherry-picks pieces of ICE
> > and
> > > I'm just not sure that it's a complete specification when put all
> > > together. I have noted a number of places where I actually am not
> > sure
> > > how to implement something, and fixing those will resolve this
> > > DISCUSS, but IMO you really should totally rewrite this document
> > > either (a) as a variant of ICE or (b) as an entirely new document
> > not
> > > with a pile of new text and then references out to ICE sections.
> >
> > the expected receivers of the work are the implementers of RFC5770,
> > so
> > the draft follows the sectioning of the RFC5770 (which has two
> > interoperable implementations).
> >
> > If I understood your comment right, the variant of ICE (a) would
> > follow
> > the ICE document structure but then the document would not serve
> > anymore
> > HIP implementers so well. What comes to option (b), I think it
> > would
> > make the the document quite long if we replicated everything in the
> > ICE
> > specification (and possibly from the HIP specifications) in the
> > draft.
>
> Yes, it would be long, because ICE is complicated. It would also be
> complete.
> As I said in my initial ballot, if you resolve the ambiguities I
> noted I will
> clear my DISCUSS, but I think that this document should really be
> rewritten
> and i would urge the AD to require it.
>
>
>
> > > S 4.6.2.
> > >>
> > >>   A host may receive a connectivity check before it has
> > received the
> > >>   candidates from its peer.  In such a case, the host MUST
> > immediately
> > >>   generate a response, and then continue waiting for the
> > candidates.  A
> > >>   host MUST NOT select a candidate pair until it has
> > verified the pair
> > >>   using a connectivity check as defined in Section 4.6.1.
> > >
> > > Are you supposed to put this on a TODO check list as with ICE?
> >
> > I believe you refer to the triggered-check queue:
> >
> > 

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Eric,

ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > S 5.8.
> > > > >>
> > > > >>5.8.  RELAY_HMAC Parameter
> > > > >>
> > > > >>   As specified in Legacy ICE-HIP [RFC5770], the
> > RELAY_HMAC
> > > > parameter
> > > > >>   value has the TLV type 65520.  It has the same
> > semantics
> > > > as RVS_HMAC
> > > > >>   [RFC8004].
> > > > > 
> > > > > What key is used for the HMAC?
> > > > 
> > > > clarified this as follows:
> > > > 
> > > > [..] It has the same semantics as RVS_HMAC as specified in
> > section
> > > > 4.2.1 
> > > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is
> > is
> > > > keyed 
> > > > with the HIP integrity key (HIP-lg or HIP-gl as specified in
> > > > section 6.5 
> > > > in [RFC7401]), established during the relay registration
> > procedure
> > > > as 
> > > > described in Section 4.1.
> > > 
> > > This seems like it might have potential for cross-protocol
> > attacks on
> > > the key. Why
> > > is this OK>
> > 
> > this is standard way of deriving keys in HIP. The keying procedure
> > is
> > the same as with specified in RFC8004. If there is some attack
> > scenario, please describe it in detail?
> > Or is there some editorial issue here?
> 
> I'm not sure. When I read this text it appears to say that you should
> be using the same key for two kinds of messages. Is that correct?

the key is always specific to a Host Association, i.e., unique between
a Relay Client and a Relay Server. So if there is a Rendezvous server
(used with RVS_HMAC), this would be a different host and different Host
Association. If the same host provides both rendezvous and relay
service, it should be fine to reuse the same key.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

I am no longer an area director, so generally I  suggest you take up these
comments with the current ADs.

On Wed, Feb 19, 2020 at 1:08 PM Miika Komu  wrote:

> Hi Eric,
>
> thanks for your comments, my response below.
>
> ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
> >
> >
> > On Wed, Nov 7, 2018 at 1:37 PM Miika Komu 
> > wrote:
> > > Hi Eric,
> > >
> > > apologies for the belated response, I am not working on HIP
> > > anymore, so
> > > it has been rather difficult to find time for this.
> > >
> > > On 5/4/18 22:34, Eric Rescorla wrote:
> > > > Eric Rescorla has entered the following ballot position for
> > > > draft-ietf-hip-native-nat-traversal-28: Discuss
> > > >
> > > > 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/
> > > >
> > > >
> > > >
> > > > ---
> > > ---
> > > > DISCUSS:
> > > > ---
> > > ---
> > > >
> > > > Rich version of this review at:
> > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> > > >
> > > >
> > > > I am very familiar with ICE and yet I found this document
> > > extremely
> > > > hard to follow. The problem is that it cherry-picks pieces of ICE
> > > and
> > > > I'm just not sure that it's a complete specification when put all
> > > > together. I have noted a number of places where I actually am not
> > > sure
> > > > how to implement something, and fixing those will resolve this
> > > > DISCUSS, but IMO you really should totally rewrite this document
> > > > either (a) as a variant of ICE or (b) as an entirely new document
> > > not
> > > > with a pile of new text and then references out to ICE sections.
> > >
> > > the expected receivers of the work are the implementers of RFC5770,
> > > so
> > > the draft follows the sectioning of the RFC5770 (which has two
> > > interoperable implementations).
> > >
> > > If I understood your comment right, the variant of ICE (a) would
> > > follow
> > > the ICE document structure but then the document would not serve
> > > anymore
> > > HIP implementers so well. What comes to option (b), I think it
> > > would
> > > make the the document quite long if we replicated everything in the
> > > ICE
> > > specification (and possibly from the HIP specifications) in the
> > > draft.
> >
> > Yes, it would be long, because ICE is complicated. It would also be
> > complete.
> > As I said in my initial ballot, if you resolve the ambiguities I
> > noted I will
> > clear my DISCUSS, but I think that this document should really be
> > rewritten
> > and i would urge the AD to require it.
> >
> >
> >
> > > > S 4.6.2.
> > > >>
> > > >>   A host may receive a connectivity check before it has
> > > received the
> > > >>   candidates from its peer.  In such a case, the host MUST
> > > immediately
> > > >>   generate a response, and then continue waiting for the
> > > candidates.  A
> > > >>   host MUST NOT select a candidate pair until it has
> > > verified the pair
> > > >>   using a connectivity check as defined in Section 4.6.1.
> > > >
> > > > Are you supposed to put this on a TODO check list as with ICE?
> > >
> > > I believe you refer to the triggered-check queue:
> > >
> > > https://tools.ietf.org/html/rfc8445#section-6.1.4.1
> > >
> > > I changed the text as follows:
> > >
> > > A host may receive a connectivity check before it has
> > >
> > > received the candidates from its peer. In such a case, the
> > >
> > > host MUST immediately generate a response by placing it in the
> > > triggered-check queue, and then continue
> > > waiting for the candidates.
> >
> > Well, this isn't generating a response, it's queueing a response.
>
> reworded as follows:
>
> In such a case, the host MUST immediately queue a response by placing
> it in the triggered-check queue, and  then continue waiting for the
> candidates.
>
> > > > S 5.8.
> > > >>
> > > >>5.8.  RELAY_HMAC Parameter
> > > >>
> > > >>   As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC
> > > parameter
> > > >>   value has the TLV type 65520.  It has the same semantics
> > > as RVS_HMAC
> > > >>   [RFC8004].
> > > >
> > > > What key is used for the HMAC?
> > >
> > > clarified this as follows:
> > >
> > > [..] It has the same semantics as RVS_HMAC as specified in section
> > > 4.2.1
> > > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is is
> > > keyed
> > > with the HIP integrity key (HIP-lg or HIP-gl 

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Eric,

thanks for your comments, my response below.

ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
> 
> 
> On Wed, Nov 7, 2018 at 1:37 PM Miika Komu 
> wrote:
> > Hi Eric,
> > 
> > apologies for the belated response, I am not working on HIP
> > anymore, so 
> > it has been rather difficult to find time for this.
> > 
> > On 5/4/18 22:34, Eric Rescorla wrote:
> > > Eric Rescorla has entered the following ballot position for
> > > draft-ietf-hip-native-nat-traversal-28: Discuss
> > > 
> > > 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/
> > > 
> > > 
> > > 
> > > ---
> > ---
> > > DISCUSS:
> > > ---
> > ---
> > > 
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> > > 
> > > 
> > > I am very familiar with ICE and yet I found this document
> > extremely
> > > hard to follow. The problem is that it cherry-picks pieces of ICE
> > and
> > > I'm just not sure that it's a complete specification when put all
> > > together. I have noted a number of places where I actually am not
> > sure
> > > how to implement something, and fixing those will resolve this
> > > DISCUSS, but IMO you really should totally rewrite this document
> > > either (a) as a variant of ICE or (b) as an entirely new document
> > not
> > > with a pile of new text and then references out to ICE sections.
> > 
> > the expected receivers of the work are the implementers of RFC5770,
> > so 
> > the draft follows the sectioning of the RFC5770 (which has two 
> > interoperable implementations).
> > 
> > If I understood your comment right, the variant of ICE (a) would
> > follow 
> > the ICE document structure but then the document would not serve
> > anymore 
> > HIP implementers so well. What comes to option (b), I think it
> > would 
> > make the the document quite long if we replicated everything in the
> > ICE 
> > specification (and possibly from the HIP specifications) in the
> > draft.
> 
> Yes, it would be long, because ICE is complicated. It would also be
> complete.
> As I said in my initial ballot, if you resolve the ambiguities I
> noted I will
> clear my DISCUSS, but I think that this document should really be
> rewritten
> and i would urge the AD to require it.
> 
> 
>  
> > > S 4.6.2.
> > >>
> > >>   A host may receive a connectivity check before it has
> > received the
> > >>   candidates from its peer.  In such a case, the host MUST
> > immediately
> > >>   generate a response, and then continue waiting for the
> > candidates.  A
> > >>   host MUST NOT select a candidate pair until it has
> > verified the pair
> > >>   using a connectivity check as defined in Section 4.6.1.
> > > 
> > > Are you supposed to put this on a TODO check list as with ICE?
> > 
> > I believe you refer to the triggered-check queue:
> > 
> > https://tools.ietf.org/html/rfc8445#section-6.1.4.1
> > 
> > I changed the text as follows:
> > 
> > A host may receive a connectivity check before it has
> > 
> > received the candidates from its peer. In such a case, the
> > 
> > host MUST immediately generate a response by placing it in the 
> > triggered-check queue, and then continue
> > waiting for the candidates.
> 
> Well, this isn't generating a response, it's queueing a response.

reworded as follows:

In such a case, the host MUST immediately queue a response by placing
it in the triggered-check queue, and  then continue waiting for the
candidates.

> > > S 5.8.
> > >>
> > >>5.8.  RELAY_HMAC Parameter
> > >>
> > >>   As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC
> > parameter
> > >>   value has the TLV type 65520.  It has the same semantics
> > as RVS_HMAC
> > >>   [RFC8004].
> > > 
> > > What key is used for the HMAC?
> > 
> > clarified this as follows:
> > 
> > [..] It has the same semantics as RVS_HMAC as specified in section
> > 4.2.1 
> > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is is
> > keyed 
> > with the HIP integrity key (HIP-lg or HIP-gl as specified in
> > section 6.5 
> > in [RFC7401]), established during the relay registration procedure
> > as 
> > described in Section 4.1.
> 
> This seems like it might have potential for cross-protocol attacks on
> the key. Why
> is this OK>

this is standard way of deriving keys in HIP. The keying procedure is
the same as with specified in RFC8004. If there is some attack

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Wed, Nov 7, 2018 at 1:37 PM Miika Komu  wrote:

> Hi Eric,
>
> apologies for the belated response, I am not working on HIP anymore, so
> it has been rather difficult to find time for this.
>
> On 5/4/18 22:34, Eric Rescorla wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-hip-native-nat-traversal-28: Discuss
> >
> > 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/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> >
> >
> > I am very familiar with ICE and yet I found this document extremely
> > hard to follow. The problem is that it cherry-picks pieces of ICE and
> > I'm just not sure that it's a complete specification when put all
> > together. I have noted a number of places where I actually am not sure
> > how to implement something, and fixing those will resolve this
> > DISCUSS, but IMO you really should totally rewrite this document
> > either (a) as a variant of ICE or (b) as an entirely new document not
> > with a pile of new text and then references out to ICE sections.
>
> the expected receivers of the work are the implementers of RFC5770, so
> the draft follows the sectioning of the RFC5770 (which has two
> interoperable implementations).
>
> If I understood your comment right, the variant of ICE (a) would follow
> the ICE document structure but then the document would not serve anymore
> HIP implementers so well. What comes to option (b), I think it would
> make the the document quite long if we replicated everything in the ICE
> specification (and possibly from the HIP specifications) in the draft.
>

Yes, it would be long, because ICE is complicated. It would also be
complete.
As I said in my initial ballot, if you resolve the ambiguities I noted I
will
clear my DISCUSS, but I think that this document should really be rewritten
and i would urge the AD to require it.




> > S 4.6.2.
> >>
> >>   A host may receive a connectivity check before it has received the
> >>   candidates from its peer.  In such a case, the host MUST
> immediately
> >>   generate a response, and then continue waiting for the
> candidates.  A
> >>   host MUST NOT select a candidate pair until it has verified the
> pair
> >>   using a connectivity check as defined in Section 4.6.1.
> >
> > Are you supposed to put this on a TODO check list as with ICE?
>
> I believe you refer to the triggered-check queue:
>
> https://tools.ietf.org/html/rfc8445#section-6.1.4.1
>
> I changed the text as follows:
>
> A host may receive a connectivity check before it has
>
> received the candidates from its peer. In such a case, the
>
> host MUST immediately generate a response by placing it in the
> triggered-check queue, and then continue
> waiting for the candidates.
>

Well, this isn't generating a response, it's queueing a response.


> S 5.8.
> >>
> >>5.8.  RELAY_HMAC Parameter
> >>
> >>   As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
> >>   value has the TLV type 65520.  It has the same semantics as
> RVS_HMAC
> >>   [RFC8004].
> >
> > What key is used for the HMAC?
>
> clarified this as follows:
>
> [..] It has the same semantics as RVS_HMAC as specified in section 4.2.1
> in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed
> with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5
> in [RFC7401]), established during the relay registration procedure as
> described in Section 4.1.
>

This seems like it might have potential for cross-protocol attacks on the
key. Why
is this OK>


> > S 4.2.
> >>   deployments in order to enable it by software configuration
> update if
> >>   needed at some point.  A host SHOULD employ only a single server
> for
> >>   gathering the candidates for a single HIP association; either one
> >>   server providing both Control and Data Relay Server
> functionality, or
> >>   one Control Relay Server and also Data Relay Server if the
> >>   functionality is offered by another server.  When the relay
> service
> >
> > How does this interact with mult-layered NAT?>
>
> No different from ICE with separated STUN and TURN servers multi-layer
> NAT scenarios. Should we mention something about the issues related to
> some specific scenario?
>

Well, with multi-layered NAT, you actually want a STUN server at each 

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Eric,

apologies for the belated response, I am not working on HIP anymore, so 
it has been rather difficult to find time for this.

On 5/4/18 22:34, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-28: Discuss
> 
> 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/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3099
> 
> 
> I am very familiar with ICE and yet I found this document extremely
> hard to follow. The problem is that it cherry-picks pieces of ICE and
> I'm just not sure that it's a complete specification when put all
> together. I have noted a number of places where I actually am not sure
> how to implement something, and fixing those will resolve this
> DISCUSS, but IMO you really should totally rewrite this document
> either (a) as a variant of ICE or (b) as an entirely new document not
> with a pile of new text and then references out to ICE sections.

the expected receivers of the work are the implementers of RFC5770, so 
the draft follows the sectioning of the RFC5770 (which has two 
interoperable implementations).

If I understood your comment right, the variant of ICE (a) would follow 
the ICE document structure but then the document would not serve anymore 
HIP implementers so well. What comes to option (b), I think it would 
make the the document quite long if we replicated everything in the ICE 
specification (and possibly from the HIP specifications) in the draft.

> DETAIL
> S 4.2.
>>   request type SHOULD NOT create any state at the Control Relay Server.
>>
>>   ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are
>>   followed here.  A number of host candidates (loopback, anycast and
>>   others) should be excluded as described in the ICE specification
>>   [I-D.ietf-ice-rfc5245bis].  Relayed candidates SHOULD be gathered in
> 
> If you're going to normatively cherry-pick ICE, you need to note
> specific sections, I think.


good catch, now that the ICE specification is finally an RFC, we can add 
a reference here and to a number of other places (which I had commented 
out because the section numbering in ICE was changing).

> S 4.6.2.
>>
>>   A host may receive a connectivity check before it has received the
>>   candidates from its peer.  In such a case, the host MUST immediately
>>   generate a response, and then continue waiting for the candidates.  A
>>   host MUST NOT select a candidate pair until it has verified the pair
>>   using a connectivity check as defined in Section 4.6.1.
> 
> Are you supposed to put this on a TODO check list as with ICE?

I believe you refer to the triggered-check queue:

https://tools.ietf.org/html/rfc8445#section-6.1.4.1

I changed the text as follows:

A host may receive a connectivity check before it has

received the candidates from its peer. In such a case, the

host MUST immediately generate a response by placing it in the 
triggered-check queue, and then continue
waiting for the candidates.

> S 5.8.
>>
>>5.8.  RELAY_HMAC Parameter
>>
>>   As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
>>   value has the TLV type 65520.  It has the same semantics as RVS_HMAC
>>   [RFC8004].
> 
> What key is used for the HMAC?

clarified this as follows:

[..] It has the same semantics as RVS_HMAC as specified in section 4.2.1 
in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed 
with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 
in [RFC7401]), established during the relay registration procedure as 
described in Section 4.1.

> --
> COMMENT:
> --
> 
> S 2.
>>   Server reflexive candidate:
>>  A translated transport address of a host as observed by a Control
>>  or Data Relay Server.
>>
>>   Peer reflexive candidate:
>>  A translated transport address of a host as observed by its peer.
> 
> You should indicate which definitions are the same as ICE/STUN

these both are the same as in ICE. I have now added references to all of 
the terms to indicate their origin.

> S 3.
>>   connected to the public Internet.  To be contacted from behind a NAT,
>>   

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi,

On 05/06/2018 10:23 PM, Christer Holmberg wrote:

Hi,


The question is whether this document should re-define the HIP variations to 
ICE that RFC 5770 already does.


That may be your question, but it's not my question. My question is that I'm 
not sure this document is
sufficiently clear and unambigious to implement, given its current structure.


Sure, the may be editorial work to do, but I still think it is important to clarify 
whether the reader of this document is expected to be familiar with RFC 5770, or whether 
this document is supposed to be an "ICE variant" on its own.


we wanted to keep the same document structure as RFC5770 because the 
developers were already familiar with it (and has two interoperable 
implementations). While we tried to duplicate some RFC5770 material to 
make the specification a bit more standalone, the document is still 
aimed for people who developed RFC5770.


As you noted, the document is missing the exact section references 
because the ICE spec has been a moving target but I guess the references 
would safe to be fixed now.


Thanks Eric for the insightful technical comments. I'll try to get you 
answers as soon as possible.



Regards,

Christer




On 6 May 2018, at 22.01, Eric Rescorla  wrote:


On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg 
 wrote:
Hi,


I am very familiar with ICE and yet I found this document extremely hard to 
follow. The problem is that it cherry-picks pieces
of ICE and I'm just not sure that it's a complete specification when put all 
together. I have noted a number of places where I
actually am not sure how to implement something, and fixing those will resolve 
this DISCUSS, but IMO you really should totally
rewrite this document either (a) as a variant of ICE or (b) as an entirely new 
document not with a pile of new text and then
references out to ICE sections.


I haven't been involved in the work on this draft, so I may be wrong, but I did review 
the document and my understanding is that RFC 5770 is the "variant of ICE", and 
this document is a modification/extension to RFC 5770.

This document is a variant of ICE in the sense that it is ICE-like and 
explicitly depends on quite a bit of ICE.

-Ekr


Regards,

Christer





___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Christer Holmberg]

Hi,

>> The question is whether this document should re-define the HIP variations to 
>> ICE that RFC 5770 already does.
>
> That may be your question, but it's not my question. My question is that I'm 
> not sure this document is 
> sufficiently clear and unambigious to implement, given its current structure.

Sure, the may be editorial work to do, but I still think it is important to 
clarify whether the reader of this document is expected to be familiar with RFC 
5770, or whether this document is supposed to be an "ICE variant" on its own.

Regards,

Christer




On 6 May 2018, at 22.01, Eric Rescorla  wrote:


On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg 
 wrote:
Hi,

> I am very familiar with ICE and yet I found this document extremely hard to 
> follow. The problem is that it cherry-picks pieces 
> of ICE and I'm just not sure that it's a complete specification when put all 
> together. I have noted a number of places where I 
> actually am not sure how to implement something, and fixing those will 
> resolve this DISCUSS, but IMO you really should totally 
> rewrite this document either (a) as a variant of ICE or (b) as an entirely 
> new document not with a pile of new text and then 
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be wrong, but I did 
review the document and my understanding is that RFC 5770 is the "variant of 
ICE", and this document is a modification/extension to RFC 5770.

This document is a variant of ICE in the sense that it is ICE-like and 
explicitly depends on quite a bit of ICE.

-Ekr


Regards,

Christer



___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Sun, May 6, 2018 at 12:05 PM, Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Hi,
>
> The question is whether this document should re-define the HIP variations
> to ICE that RFC 5770 already does.
>

That may be your question, but it's not my question. My question is that
I'm not sure this document is sufficiently clear and unambigious to
implement, given its current structure.

-Ekr


> Regards,
>
> Christer
>
> Sent from my iPhone
>
> On 6 May 2018, at 22.01, Eric Rescorla  wrote:
>
>
>
> On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg <
> christer.holmb...@ericsson.com> wrote:
>
>> Hi,
>>
>> > I am very familiar with ICE and yet I found this document extremely
>> hard to follow. The problem is that it cherry-picks pieces
>> > of ICE and I'm just not sure that it's a complete specification when
>> put all together. I have noted a number of places where I
>> > actually am not sure how to implement something, and fixing those will
>> resolve this DISCUSS, but IMO you really should totally
>> > rewrite this document either (a) as a variant of ICE or (b) as an
>> entirely new document not with a pile of new text and then
>> > references out to ICE sections.
>>
>> I haven't been involved in the work on this draft, so I may be wrong, but
>> I did review the document and my understanding is that RFC 5770 is the
>> "variant of ICE", and this document is a modification/extension to RFC 5770.
>>
>
> This document is a variant of ICE in the sense that it is ICE-like and
> explicitly depends on quite a bit of ICE.
>
> -Ekr
>
>
>> Regards,
>>
>> Christer
>>
>>
>>
>
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Christer Holmberg]

Hi,

The question is whether this document should re-define the HIP variations to 
ICE that RFC 5770 already does.

Regards,

Christer

Sent from my iPhone

On 6 May 2018, at 22.01, Eric Rescorla > 
wrote:



On Sun, May 6, 2018 at 10:19 AM, Christer Holmberg 
> wrote:
Hi,

> I am very familiar with ICE and yet I found this document extremely hard to 
> follow. The problem is that it cherry-picks pieces
> of ICE and I'm just not sure that it's a complete specification when put all 
> together. I have noted a number of places where I
> actually am not sure how to implement something, and fixing those will 
> resolve this DISCUSS, but IMO you really should totally
> rewrite this document either (a) as a variant of ICE or (b) as an entirely 
> new document not with a pile of new text and then
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be wrong, but I did 
review the document and my understanding is that RFC 5770 is the "variant of 
ICE", and this document is a modification/extension to RFC 5770.

This document is a variant of ICE in the sense that it is ICE-like and 
explicitly depends on quite a bit of ICE.

-Ekr


Regards,

Christer



___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Christer Holmberg]

Hi,

> I am very familiar with ICE and yet I found this document extremely hard to 
> follow. The problem is that it cherry-picks pieces 
> of ICE and I'm just not sure that it's a complete specification when put all 
> together. I have noted a number of places where I 
> actually am not sure how to implement something, and fixing those will 
> resolve this DISCUSS, but IMO you really should totally 
> rewrite this document either (a) as a variant of ICE or (b) as an entirely 
> new document not with a pile of new text and then 
> references out to ICE sections.

I haven't been involved in the work on this draft, so I may be wrong, but I did 
review the document and my understanding is that RFC 5770 is the "variant of 
ICE", and this document is a modification/extension to RFC 5770.

Regards,

Christer


___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec