[Hipsec] Ben Campbell's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-hip-rfc4423-bis-19: 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-rfc4423-bis/



--
COMMENT:
--

I have mostly just reviewed the diff from RFC4423. My comments are mostly
editorial.

First, a minor rant that I don't expect to be addressed at this point in the
process; I mainly say this to try to discourage it future bis drafts: There are
quite a few changes from 4423 that are entirely stylistic, but do not
materially change the content or improve readability. I wish people wouldn't do
that, because it makes it harder to review material changes with the diff
tools. (I will only point out such changes where I think the original was more
correct.)

-General: There seems to have been a systematic attempt to remove hyphens from
compound adjectives. There also seems to be a systematic attempt to change
headings from title case to normal sentence case.  I suspect the RFC editor
will change those all back.

Abstract: The abstract manages to completely avoid saying what this namespace
is _for_. (Yes, I realize that is old text :-) )

§1, first paragraph: s/ "try and do"/"try to do"

§4.2: Please mention the HIT abbreviation in the text, not just the heading.
(The text should make sense even without the headings.)

§5:
- third paragraph: Missing articles before "Left" and "right".
- 2nd to last paragraph: Missing article before "HIP layer" (multiple
instances).


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

[Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: Abstain

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:
--

I support all points of Ekr's discuss and comment points. I think this either
needs to use ICE mostly as is (maybe with some minor profiling) or it needs to
be self-contained here. I understand the material in appendix B, but the
current mix seems untenable for implementors. Therefore I am balloting
"abstain".  I will reconsider that position if there is a substantial
reorganization.

Substantive Comments:

I share Alissa's question about why this is standard track when the previous
work has been experimental.

§1, second paragraph: The citation for the version of ICE used by "legacy
ICE-HIP" should be RFC5245, not the bis version.

§2: There are a number of lower-case keywords. Please use the RFC 8174
boilerplate.

§4.2:
- paragraph 5: Is everything in this paragraph from the ICE specification? I
suspect not, but it's hard to tease out what is from ICE and what is new
specification. It would be helpful to reference the ICE bits by section number.
- paragraph 6: I'm confused in that I thought the previous text said that
native ICE-HIP does not use STUN.

§6: I am skeptical of the assertion that the security considerations for Native
ICE-HIP are no different than those for Legacy ICE-HIP.

Editorial Comments:

§1, 2nd paragraph:
- "responsible of NAT traversal": s/of/to
- "responsible of end-host": s/of/to

§4.3: "This section describes the usage of a new non-critical parameter type.
": Which is?

§4.6, first paragraph: 2nd sentence is hard to parse.


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

[Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: 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:
--

I'm balloting No Objection, but I'm watching the discussion in Eric's ballot
thread about reusing pieces of ICE, and I look forward to some discussion about
the provisions being made for middleboxes in this draft - I'm not denying that
such things exist, only that it would be best if we understood why middleboxes
are needed for this usage.


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

[Hipsec] Adam Roach's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-hip-rfc4423-bis-19: 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-rfc4423-bis/



--
COMMENT:
--

Thanks for everyone's work on updating RFC 4423.

In general, I agree with Mirja's point that section 11 seems a bit disjoint
from the rest of the document, and would be better served as an appendix. It's
also somewhat jarring to have a document whose abstract talks about a "new
namespace" and a "new protocol layer," which goes on to describe conclusions
from twelve years of deployment experience. I would recommend re-working all
uses of the word "new" (which, in most cases, can be achieved by either
removing the word "new" from sentences, or replacing it with "HIP").

The remainder of my comments are editorial nits.

---

§2.1:

>  +---+---+
>  | Term  | Explanation   |
>  +---+---+
>  | Public key| The public key of an asymmetric cryptographic key |
>  |   | pair.  Used as a publicly known identifier for|
>  |   | cryptographic identity authentication.  Public is |
>  |   | a a relative term here, ranging from "known to|
>  |   | peers only" to "known to the world."  |

Nit: this text contains a doubled "a" ("...a a relative...").

---
§2.2:

Nit: The change in spacing in this table makes certain terms difficult to read
(e.g., "HIP base exchange HIP packet" appears to be a single term until the
table is closely examined.) Consider reverting to the spacing from RFC 4423.

---

§3.1:

>  o  The names should have a fixed length representation, for easy

Nit: "fixed-length" is a compound adjective, and should be hyphenated.
cf. https://www.google.com/search?q=compound+adjective

> (e.g the TCB).

Nit: The conventional form would call for "(e.g., the TCB)"
cf. https://www.google.com/search?q="e.g."+punctuation+comma

> o The names should be long lived, but replaceable at any time. This

"long-lived"

> designed, it can deliver all of the above stated requirements.

"above-stated"

---

§4:

>  In theory, any name that can claim to be 'statistically globally
>  unique' may serve as a Host Identifier.  In the HIP architecture, the
>  public key of a private-public key pair has been chosen as the Host
>  Identifier because it can be self managed and it is computationally

"self-managed"

---

§6.5:

>  The control plane between two hosts is terminated using a secure two
>  message exchange as specified in base exchange specification

"two-message"

---

§7:

>  control plane, protected by asymmetric key cryptography.  Also, S-RTP
>  has been considered as the data encapsulation protocol [hip-srtp].

"SRTP" rather than "S-RTP".

---

§8:

>  Besides this "native" NAT traversal mode for HIP, other NAT traversal
>  mechanisms have been successfully utilized, such as Teredo
>  [varjonen-split].

Please cite RFC 4380 for "Teredo." e.g.:

   Besides this "native" NAT traversal mode for HIP, other NAT traversal
   mechanisms have been successfully utilized, such as Teredo [RFC4380],
   as described in [varjonen-split].



---

§8:

>  can map to a single IP address on a NAT, simplifying connections on
>  address poor NAT interfaces.  The NAT can gain much of its knowledge

"address-poor"

---

§11.1:

> Considering such human errors, a site
> employing location-independent identifiers as promoted by HIP may
> experience less problems while renumbering their network.

"...experience fewer problems..."

>  o  HITs (or LSIs) can be used in IP-based access control lists as a
> more secure replacement for IPv6 addresses.  Besides security, HIT
>   

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

[Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-rfc4423-bis-19: 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-rfc4423-bis/



--
COMMENT:
--

I share Eric's concerns about the need for
second-preimage-resistance from the hash, and in particular with the
birthday bound, it's unclear that using a 128-bit hash leaves a very
large margin for growth.

Some other section-by-section notes follow.

Section 1

   [...] HIP provides for limited forms of trust between systems,
   enhance mobility, multi-homing and dynamic IP renumbering, aid in
   protocol translation / transition, and reduce certain types of
   denial-of-service (DoS) attacks.

I think that something is weird here with singular vs. plural in the
list elements.


Section 4

I agree with the secdir reviewer's not about "SHOULD NOT [implement
non-cryptographic HIP]"


Section 5.1

   At the client side, a host may have multiple Host Identities, for
   instance, for privacy purposes.  Another reason can be that the
   person utilizing the host employs different identities for different
   administrative domains as an extra security measure.  If a HIP-aware
   middlebox, such as a HIP-based firewall, is on the path between the
   client and server, the user or the underlying system should carefully
   choose the correct identity to avoid the firewall to unnecessarily
   drop HIP-based connectivity [komu-diss].

In addition to the firewall case, choosing the correct identifier
can also impact the privacy considerations, as a given identifier
would be trackable by on-path entities.


Section 6.2

   When a node moves while communication is already on-going, address
   changes are rather straightforward.  The peer of the mobile node can
   just accept a HIP or an integrity protected ESP packet from any
   address and ignore the source address.  However, as discussed in
   Section 12.2 below, a mobile node must send a HIP UPDATE packet to
   inform the peer of the new address(es), and the peer must verify that
   the mobile node is reachable through these addresses.

Am I reading this right that from a technical perspective, the peer
can just accept stuff from wherever, but from a policy/protocol
perspective the UPDATE requirement is included?  The text could
probably be a bit more clear, potentially even without using RFC
2119 language.


Section 10

   There are a number of variables that influence the HIP exchange that
   each host must support.  All HIP implementations should support at
   least 2 HIs, one to publish in DNS or similar directory service and
   an unpublished one for anonymous usage.  Although unpublished HIs

I suggest a parenthetical that the unpublished one should expect to
be rotated frequently in order to disrupt linkability/trackability.

   will be rarely used as responder HIs, they are likely to be common
   for initiators.  Support for multiple HIs is recommended.  [...]

If multiple means "more than two", it's probably better to say that.
(If multiple means "more than one", this is just a weaker version of
"should support at least 2", above.)  And it's rather tempting to
make it a MUST, anyway.

   Many initiators would want to use a different HI for different
   responders.  The implementations should provide for a policy mapping
   of initiator HITs to responder HITs.  This policy should also include
   preferred transforms and local lifetimes.

"mapping of initiator to responder" is potentially confusing, in
that in practice the procedure will be "I want to talk to responder
A, so let me look up that I use HIT X to talk to responder A", which
is the opposite direction from this text.


Section 11.1

I'd consider replacing "is an attempt to" with "attempts to" -- for
example, IPv6 tries to do a lot of things in addition to killing
NAT!


Section 11.3.1

   [...]Second, a
   data plane component is needed.  Most HIP implementations utilize the
   so called BEET mode of ESP that has been available since Linux kernel
   2.6.27, but is included also as a userspace component in a few of the
   implementations.

Nit: "but ESP is included", I think.


Section 12.1

I don't understand the usage of "a-priori" in:
   The need to support multiple hashes for generating the HIT from the
   HI affords the MitM to mount a potentially powerful downgrade attack
   due to the a-priori need of the HIT in the HIP base exchange.


   In HIP, the Security Association for ESP is indexed by the 

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

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: 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:
--

Like Benjamin, I also found the relationship between this document and ICE
somewhat confusing until the very end (Appendix B).  The attempt to "follow ICE
methodology but reuse HIP messaging format to achieve the same functionality"
results in lack of clarity, so I also agree with Eric's opinion that a rewrite
would help, and support his DISCUSS.


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

Re: [Hipsec] [Gen-art] Genart telechat review of draft-ietf-hip-native-nat-traversal-28

[Alissa Cooper]

Roni, thanks for your review. Miika, thanks for your response. I have entered a 
No Objection ballot.

Alissa

> On Apr 9, 2018, at 8:05 AM, Miika Komu  wrote:
> 
> Hi Roni,
> 
> On 04/08/2018 10:32 AM, Roni Even wrote:
>> Reviewer: Roni Even
>> Review result: Ready with Nits
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>> For more information, please see the FAQ at
>> .
>> Document: draft-ietf-hip-native-nat-traversal-??
>> Reviewer: Roni Even
>> Review Date: 2018-04-08
>> IETF LC End Date: 2018-02-26
>> IESG Telechat date: 2018-05-10
>> Summary:
>> The document is ready for publication as a standard track RFC with one nit.
>> Major issues:
>> Minor issues:
>> Nits/editorial comments:
>> In section 7 - "a new error type  
>> SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED
>> in Section 5.9." It is in section 5.10
> 
> good catch, I'll fix the reference in the next version. Thanks!
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

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

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: 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:
--

I admit to not having much familiarity with HIP, so apologies if some of these
questions seem off-base.

Why is this document on the standards track when RFC 5770 was experimental?

Section 6.1 says:

"The locators are in plain text format in favor of inspection at HIP-
   aware middleboxes in the future.  The current document does not
   specify encrypted versions of LOCATOR_SETs, even though it could be
   beneficial for privacy reasons to avoid disclosing them to
   middleboxes."

This seems to cut in the opposite direction of some of the other work we have
going on in the IETF, where the justification for maintaining header
information in the clear is for backwards-compatability with existing
middleboxes, not to facilitate some to-be-developed middlebox behavior. Why is
this justified for HIP?

Section 6.1 also says "an end-host may exclude certain host addresses from its
LOCATOR_SET parameter," but I don't think this is totally clear in Section 4.5
where it talks about "all the HIP candidates." I also wonder if it would be
possible to provide some guidance about the circumstances under which an
initiator might choose to exclude certain addresses, e.g. if there is a common
deployment scenario where it's clear that certain candidates are meant to
remain private.

Nits:

= Section 1 =

" As one solution, the HIP experiment report [RFC6538] mentions that
   Teredo based NAT traversal for HIP and related ESP traffic (with
   double tunneling overhead)."

This is a sentence fragment.

= Section 2 =

The paragraph about RFC2119 should also reference RFC8174.


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

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

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: 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:
--

This document does a poor job at convincing me that there
is a need to re-specify ICE for use in HIP contexts as opposed to
just using ICE directly, up until Appendix B.  I'd suggest moving
some of the key points into at least the Introduction and arguably
the Abstract as well, to make it clear that this is not just
needless duplication for ideological purity.

I think there's some lingering terminology confusion (as a result of
needing to align the new bits in Native HIP-ICE with those retained
from RFC 5077, along with the move from 5245 to 5245bis.
Specifically, while it's fine for this document to refer to "ICE
offer" and "ICE answer", 5245bis itself does not talk of "offer" and
"answer", which are now concepts only in SDP, IIUC.  Things also
seem a bit hazy about server reflexive vs. server relay candidates
(though maybe here the confusion is just on my end) -- in regular
ICE, a server reflexive candidate is obtained by a STUN client
making a one-shot request of a STUN server to find out what address
is being used on the other side of a NAT, and doesn't require any
state on the STUN server.  But in this document we have a
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED Notify/error packet
that implies that state is needed on the Data Relay Server for a
reflexive candidate, text about "when the relay service is split
between hosts, the server reflexive candidate [from Control SHOULD
be used over the one from Data]", and also other discussion about
needing to register new reflexive candidates to avoid collisions or
in potential multihoming future work.

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?


Section 3

   [...] At this point, also the HIP signaling can be sent over the
   same address/port pair, and is demultiplexed from IPsec as described
   in the UDP encapsulation standard for IPsec [RFC3948].

"demultiplex" does not appear anywhere in RFC 3948; it might be
worth using a few more words here to clarify what is going on.


Section 4.1

   A Control Relay Server MUST silently drop packets to a Control Relay
   Client that has not previously registered with the HIP relay.

How does the relay know where they are targetted without the
registration information?

   This applies both renewals of service registration but also to host
   movement, where especially the latter requires the Control Relay
   Client to learn its new server reflexive address candidate.

This is kind of awkward wording; maybe:

   This applies to both renewals of service registration and to host
   movement.  It is especially important for the case of host
   movement, as this is the mechanism that allows the Control Relay
   Client to learn its new server reflexive address candidate.


Section 4.2

   [...] 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.

The second half of this sentence seems to contradict the SHOULD, so
probably some rewording is in order.

   [...] If a relayed candidate is identical to a host
   candidate, the relayed candidate must be discarded.  NAT64
   considerations in [I-D.ietf-ice-rfc5245bis] apply as well.

I don't think this has enough detail of reference to ICE -- a
relayed candidate being identical to a host candidate is, IIUC,
quite unexpected.  This is even noted in 5245bis, at the bottom of
page 20 (of the -20).

   Unlike ICE, this protocol only creates a single UDP flow between the
   two communicating hosts, so only a single component exists.  Hence,
   the component ID value MUST always be set to 1.

ICE or SDP?


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