Re: [Hipsec] [Errata Verified] RFC7401 (6654)

[Miika Komu]

Hi,

the corrected text is valid.

to, 2021-08-05 kello 01:55 -0700, RFC Errata System kirjoitti:
> The following errata report has been verified for RFC7401,
> "Host Identity Protocol Version 2 (HIPv2)". 
> 
> --
> You may review the report below and at:
> 
https://protect2.fireeye.com/v1/url?k=a45951b5-fbc268f1-a459112e-861d41abace8-8133344cbdf457f6=1=3ae1a2e5-329c-4c92-9346-a91793d115fa=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6654
> 
> --
> Status: Verified
> Type: Technical
> 
> Reported by: Nikolai Malykh 
> Date Reported: 2021-08-04
> Verified by: Eric Vyncke (IESG)
> 
> Section: 5.3.3
> 
> Original Text
> -
>If present in the I1 packet, the Initiator MUST include an
> unmodified
>copy of the R1_COUNTER parameter received in the corresponding R1
>packet into the I2 packet.
> 
> 
> Corrected Text
> --
>If present in the R1 packet, the Initiator MUST include an
> unmodified
>copy of the R1_COUNTER parameter received in the corresponding R1
>packet into the I2 packet.
> 
> 
> Notes
> -
> Packet name error, must be R1
> 
> --
> RFC7401 (draft-ietf-hip-rfc5201-bis-20)
> --
> Title   : Host Identity Protocol Version 2 (HIPv2)
> Publication Date: April 2015
> Author(s)   : R. Moskowitz, Ed., T. Heer, P. Jokela, T.
> Henderson
> Category: PROPOSED STANDARD
> Source  : Host Identity Protocol
> Area: Internet
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Future of draft-ietf-hip-dex

[Miika Komu]

Hi,

for what it's worth, I would ok with experimental status due to lack of
PFS but I believe Robert would disagree.

ti, 2021-06-29 kello 07:19 +, Eric Vyncke (evyncke) kirjoitti:
> I meant experimental and not informational (sorry about any
> confusion)
> 
> -éric
> 
> -Original Message-----
> From: Miika Komu 
> Date: Tuesday, 29 June 2021 at 09:10
> To: "r...@htt-consult.com" , "
> rene.hum...@belden.com" , Gonzalo Camarillo <
> gonzalo.camari...@ericsson.com>, Eric Vyncke 
> Cc: "hipsec@ietf.org" 
> Subject: Re: Future of draft-ietf-hip-dex
> 
> Hi Eric,
> 
> I know Robert is going for standards track but is experimental
> track
> out of question? Maybe informal is not so good because the draft
> specifies an actual protocol.
> 
> Besides this, most of discuss points require Robert's expertise.
> 
> ma, 2021-06-28 kello 13:51 +, Eric Vyncke (evyncke)
> kirjoitti:
> > In the absence of reaction on draft-ietf-hip-dex being back to
> the
> > HIP WG, let me explain its current status.
> > 
> > The draft-ietf-hip-dex draft has not been accepted by the IESG
> in
> > March 2021 and has been sent back to the HIP WG in order to
> address
> > multiple DISCUSS blocking points raised by the IESG... A change
> of
> > intended status to 'informal' could also help the publication
> as well
> > as strong argumentation that DEX is actually required on
> constrained
> > devices in 2021.
> > 
> > What is the plan of the authors and of the HIP WG on this topic
> ?
> > Declaring the I-D dead is also possible of course. But, the I-D
> > should not stay in the limbo forever.
> > 
> > Regards
> > 
> > -éric
> >  
> > 
> 
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Future of draft-ietf-hip-dex

[Miika Komu]

Hi Eric,

I know Robert is going for standards track but is experimental track
out of question? Maybe informal is not so good because the draft
specifies an actual protocol.

Besides this, most of discuss points require Robert's expertise.

ma, 2021-06-28 kello 13:51 +, Eric Vyncke (evyncke) kirjoitti:
> In the absence of reaction on draft-ietf-hip-dex being back to the
> HIP WG, let me explain its current status.
> 
> The draft-ietf-hip-dex draft has not been accepted by the IESG in
> March 2021 and has been sent back to the HIP WG in order to address
> multiple DISCUSS blocking points raised by the IESG... A change of
> intended status to 'informal' could also help the publication as well
> as strong argumentation that DEX is actually required on constrained
> devices in 2021.
> 
> What is the plan of the authors and of the HIP WG on this topic ?
> Declaring the I-D dead is also possible of course. But, the I-D
> should not stay in the limbo forever.
> 
> Regards
> 
> -éric
>  
> 
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Questions about HIP

[Miika Komu]

Hi,

la, 2021-05-22 kello 11:59 +0800, peng.sha...@zte.com.cn kirjoitti:
> 
> Hi WG,
> 
> Recently, I learned some HIP protocols. Thanks for the knowledge
> provided by the group.
> I have a doubt that it seems that HIP is not deployed much in
> reality. Can someone tell me why?

Tempered networks has successfully commercialized HIP:

https://www.tempered.io/

Have a look at:

https://www.sciencedirect.com/science/article/abs/pii/S1389128613000480

... and search for,e.g., deployment in here:

https://datatracker.ietf.org/doc/html/rfc6538

IMHO, the process in the IETF via experimental track influenced also
adoption.

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

Re: [Hipsec] Status of HIP-DEX/BEX implementations

[Miika Komu]

Hi Eric,

ti, 2020-07-14 kello 11:45 +, Eric Vyncke (evyncke) kirjoitti:
> [Bcc previous and current authors in HIP related documents]
>  
> In the framework of the IESG evaluation of HIP-DEX, it would be
> useful to know whether there are implementations of HIP-DEX.

sorry for not sending this earlier due to my vacations. I am aware of
three implementations (no idea about interoperability):

1. Contiki-based implementation 
https://www.researchgate.net/publication/259475424_Slimfit_-_A_HIP_DEX_compression_layer_for_the_IP-based_Internet_of_Things

2. Java: https://code.google.com/archive/p/hip-dex/

3. Java: https://github.com/juhovh/hip-dex/tree/master/SpotHIP
 
> In the same vein, getting a list of HIPv2 BEX (Base Exchange) would
> also be useful.

AFAIK, HIPv2 has been implemented and interoperated successfully by the
following implementations:

1. OpenHIP
2. HIP for Linux

(Maybe also by the HIP4Inter.net implementation but I am not sure about
this)
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Magnus Westerlund's No Objection on draft-ietf-hip-native-nat-traversal-32: (with COMMENT)

[Miika Komu]

Hi Magnus,

ti, 2020-07-28 kello 07:44 -0700, Magnus Westerlund via Datatracker
kirjoitti:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-32: 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 resolving and answering my questions.
> 
> I have only one minor comment that I noticed due to that you edit the
> text:
> 
> Section 2:
> "Following [RFC5770] and SDP [RFC3264] ..."
> 
> RFC 3264 is not SDP, it is the "Offer/Answer model with SDP" there is
> a
> significant difference, as SDP base spec is RFC4566.

how about:

SDP related naming conventions [RFC3264]

or just:

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

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

[Miika Komu]

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

Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Benjamin,

ti, 2020-03-03 kello 20:09 -0800, Benjamin Kaduk via Datatracker
kirjoitti:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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:
> ---
> ---
> 
> One fairly minor point to start: Section 4.3 says that we define a
> new
> mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but
> then
> goes on to say that "the presence of the parameter in a HIP base
> exchange means that the end-host supports NAT traversal extensions
> defined in this document".  If I undrestand correctly, only the
> specific
> presence of the ICE-HIP-UDP mode of the NAT_TRAVERSAL_MODE parameter
> does so, and so to say that the presence of "the [NAT_TRAVERSAL_MODE]
> parameter" indicates support for this document would be backwards
> incompatible with RFC 5770.
> 
> I'd also like to delve a little further into the potential
> "cross-protocol" attack (same protocol, really, but the same attack)
> that Ekr raised, between RVS_HMAC and RELAY_HMAC.  This is probably a
> "discuss discuss", so let's see where it leads...
> 
> The semantics for either type of HMAC is that it is an HMAC over the
> HIP
> packet excluding itself and subsequent parameters.  Pulling up the
> HIP
> packet format from RFC 7401, that looks like:
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Next Header   | Header Length |0| Packet Type |Version| RES.|1|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Checksum |   Controls|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|Sender's Host Identity Tag (HIT)   |
>|   |
>|   |
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Receiver's Host Identity Tag (HIT)  |
>|   |
>|   |
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   |
>/HIP Parameters /
>/   /
>|   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The HMAC key is the integrity key for that direction of traffic
> between
> HITs, so the "cross-protocol" part can only come in by confusing the
> packet recipient into confusion as to whether it is processing an
> RVS_HMAC or a RELAY_HMAC (but any other entity will reject the packet
> by
> virtue of it using the wrong key).  Modern best practices are to go
> through a key derivation step that incorporates as much information
> as
> possible about what the derived key will be used for, which would in
> this case include the TLV type of the HMAC parameter and presumably
> the
> HITs in question as well.
> 
> In particular, the TLV type of the HMAC parameter is *not* input into
> the HMAC calculation (at least for RVS_HMAC), so the trivial
> discriminator is not present.  The "packet type" in the header in the
> header is potentially going to differ across usages, so I think
> that's a
> good place to focus discussion.  Unfortunately, Section 4.2.1 of RFC
> 8004 suggests that RVS_HMAC is going to be present a lot of the time,
> so
> it's not really clear to me what packet types either RVS_HMAC and/or
> REPLAY_HMAC are expected to occur in.  Could a HIP expert please jump
> in
> and help clarify?

let's iterate this further. I think the security concern here is
generic but no specific attack scenario. At this point of
standardization,
I am bit hesitant to do any drastic changes to this unless there is
some
clear attack.

So the parameters can be in the following messages:

* 

Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

I noticed that the new proposed text on DNS is handling things
differently than this part in RFC5770:

https://tools.ietf.org/html/rfc5770#appendix-B

So I would suggest that we would update RFC5770 appendix B in the
native NAT traversal draft and replace it with the new DNS text. Would
you be ok with this?

ma, 2020-04-06 kello 13:44 +, Jeff Ahrenholz kirjoitti:
> Miika,
> Looks good to me. I like how the distinction between RVS and Control
> Relay Server  is spelled out.
> 
> Just a couple of nits:
> s/an HIP/ a HIP/
> s/the the A/the A/
> 
> -Jeff
> 
> On 4/5/20, 6:20 AM, "Hipsec on behalf of Miika Komu" <
> hipsec-boun...@ietf.org on behalf of 
> miika.komu=40ericsson@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> during IESG review Magnus Westerlund asked about DNS support in
> draft-
> ietf-hip-native-nat-traversal, so I added the the text below to
> draft-
> ietf-hip-native-nat-traversal. Does it seem ok for the WG?
> 
> Appendix E.  DNS Considerations
> 
> [RFC5770] did not specify how an end-host can look up another
> end-
> host via DNS and initiate an UDP-based HIP base exchange with it,
> so
> this section makes an attempt to fill this gap.
> 
> [RFC8005] specifies how an HIP end-host and its Rendezvous server
> is
> registered to DNS.  Essentially, the public key of the end-host
> is
> stored as HI record and its Rendezvous Server as A or 
> record.
> This way, the Rendezvous Server can act as an intermediary for
> the
> end-host and forward packets to it based on the DNS
> configuration.
> Control Relay Server offers similar functionality as Rendezvous
> Server, with the difference that the Control Relay Server
> forwards
> all control messages, not just the first I1 message.
> 
> Prior to this document, the A and  records in the DNS refer
> either to the HIP end-host itself or a Rendezvous Server
> [RFC8005],
> and control and data plane communication with the associated host
> has
> been assumed to occur directly over IPv4 or IPv6.  However, this
> specification extends the records to be used for UDP-based
> communications.
> 
> Let us consider the case of a HIP Initiator with the default
> policy
> to employ UDP encapsulation and the extensions defined in this
> document.  The Initiator looks up the FQDN of a Responder, and
> retrieves its HI, A and  records.  Since the default policy
> is to
> use UDP encapsulation, the Initiator MUST send the I1 message
> over
> UDP to destination port 10500 (either over IPv4 in the case of a
> A
> record or over IPv6 in the case of a  record).  It MAY send
> an I1
> message both with and without UDP encapsulation in parallel.  In
> the
> case the Initiator receives R1 messages both with and without UDP
> encapsulation from the Responder, the Initiator SHOULD ignore the
> R1
> messages without UDP encapsulation.
> 
> The UDP encapsulated I1 packet could be received by three
> different
> types of hosts:
> 
> 1.  HIP Control Relay Server: in this case the A/ records
> refers
> to a Control Relay Server, and it will forward the packet to
> the
> corresponding Control Relay Client based on the destination
> HIT
> in the I1 packet.
> 
> 2.  HIP Responder supporting UDP encapsulation: in this case, the
> the
> A/ records refers to the end-host.  Assuming the
> destination
> HIT belongs to the Responder, it receives and processes it
> according to the negotiated NAT traversal mechanism.  The
> support
> for the protocol defined in this document vs [RFC5770] is
> dynamically negotiated during the base exchange.  The details
> are
> specified in Section 4.3.
> 
> 3.  HIP Rendezvous Server: this entity is not listening to UDP
> port
> 10500, so it will drop the I1 message.
> 
> 4.  HIP Responder not supporting UDP encapsulation: the targeted
> end-
>host is not listening to UDP port 10500, so it will drop
> the I1
>message.
> 
> The A/-record MUST NOT be configured to refer to a Data Relay
> Server unless the host in question supports also Control Relay
> Server
> functionality.
> 
> It also worth noting that SRV records are not employed in this
> specification.  While they could be used for more flexible UDP
> port
> selection, they are not suitable for end-host discovery but
> rather
> 

Re: [Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal

[Miika Komu]

Thanks Jeff,

your nits will be included in the next version.

ma, 2020-04-06 kello 13:44 +, Jeff Ahrenholz kirjoitti:
> Miika,
> Looks good to me. I like how the distinction between RVS and Control
> Relay Server  is spelled out.
> 
> Just a couple of nits:
> s/an HIP/ a HIP/
> s/the the A/the A/
> 
> -Jeff
> 
> On 4/5/20, 6:20 AM, "Hipsec on behalf of Miika Komu" <
> hipsec-boun...@ietf.org on behalf of 
> miika.komu=40ericsson@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> during IESG review Magnus Westerlund asked about DNS support in
> draft-
> ietf-hip-native-nat-traversal, so I added the the text below to
> draft-
> ietf-hip-native-nat-traversal. Does it seem ok for the WG?
> 
> Appendix E.  DNS Considerations
> 
> [RFC5770] did not specify how an end-host can look up another
> end-
> host via DNS and initiate an UDP-based HIP base exchange with it,
> so
> this section makes an attempt to fill this gap.
> 
> [RFC8005] specifies how an HIP end-host and its Rendezvous server
> is
> registered to DNS.  Essentially, the public key of the end-host
> is
> stored as HI record and its Rendezvous Server as A or 
> record.
> This way, the Rendezvous Server can act as an intermediary for
> the
> end-host and forward packets to it based on the DNS
> configuration.
> Control Relay Server offers similar functionality as Rendezvous
> Server, with the difference that the Control Relay Server
> forwards
> all control messages, not just the first I1 message.
> 
> Prior to this document, the A and  records in the DNS refer
> either to the HIP end-host itself or a Rendezvous Server
> [RFC8005],
> and control and data plane communication with the associated host
> has
> been assumed to occur directly over IPv4 or IPv6.  However, this
> specification extends the records to be used for UDP-based
> communications.
> 
> Let us consider the case of a HIP Initiator with the default
> policy
> to employ UDP encapsulation and the extensions defined in this
> document.  The Initiator looks up the FQDN of a Responder, and
> retrieves its HI, A and  records.  Since the default policy
> is to
> use UDP encapsulation, the Initiator MUST send the I1 message
> over
> UDP to destination port 10500 (either over IPv4 in the case of a
> A
> record or over IPv6 in the case of a  record).  It MAY send
> an I1
> message both with and without UDP encapsulation in parallel.  In
> the
> case the Initiator receives R1 messages both with and without UDP
> encapsulation from the Responder, the Initiator SHOULD ignore the
> R1
> messages without UDP encapsulation.
> 
> The UDP encapsulated I1 packet could be received by three
> different
> types of hosts:
> 
> 1.  HIP Control Relay Server: in this case the A/ records
> refers
> to a Control Relay Server, and it will forward the packet to
> the
> corresponding Control Relay Client based on the destination
> HIT
> in the I1 packet.
> 
> 2.  HIP Responder supporting UDP encapsulation: in this case, the
> the
> A/ records refers to the end-host.  Assuming the
> destination
> HIT belongs to the Responder, it receives and processes it
> according to the negotiated NAT traversal mechanism.  The
> support
> for the protocol defined in this document vs [RFC5770] is
> dynamically negotiated during the base exchange.  The details
> are
> specified in Section 4.3.
> 
> 3.  HIP Rendezvous Server: this entity is not listening to UDP
> port
> 10500, so it will drop the I1 message.
> 
> 4.  HIP Responder not supporting UDP encapsulation: the targeted
> end-
>host is not listening to UDP port 10500, so it will drop
> the I1
>message.
> 
> The A/-record MUST NOT be configured to refer to a Data Relay
> Server unless the host in question supports also Control Relay
> Server
> functionality.
> 
> It also worth noting that SRV records are not employed in this
> specification.  While they could be used for more flexible UDP
> port
> selection, they are not suitable for end-host discovery but
> rather
> would be more suitable for the discovery of HIP-specific
> infrastructure.  Further extensions to this document may define
> SRV
> records for Control and Data Relay Server discovery within a DNS
> domain.
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
> 
> 
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Barry Leiba's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)

[Miika Komu]

Hi Barry,

ke, 2020-03-04 kello 21:07 -0800, Barry Leiba via Datatracker
kirjoitti:
> Barry Leiba has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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:
> ---
> ---
> 
> Given this document’s dependency on concepts and terminology from
> 5770, I think
> that document has to be a normative reference.  Can someone really
> understand
> and implement this without any reference to 5770?

I changed the refence to normative.

> — Abstract —
> 
>The main
>difference from the previously specified modes is the use of HIP
>messages instead of ICE for all NAT traversal procedures due to
> its
>kernel-space dependencies.
> 
> The antecedent to “its” is unclear: it could be “use of HIP
> messages”, or
> “ICE”, or “NAT traversal”.  Please rephrase to clarify.

changed to "due to the kernel-space dependencies of HIP".

> — Section 1 —
> 
>Also, especially NATs usually require the
>host behind a NAT to create a forwarding state in the NAT before
>other hosts outside of the NAT can contact the
> 
> What does “especially” mean in this sentence?  It doesn’t make sense
> to me. 
> Does it add anything?

I removed it.

>which will be referred as "Legacy ICE-HIP" in this document.
> 
> Nit: “referred to”

changed as suggested

>HIP poses a unique challenge to using standard ICE, due not only
> to
>its kernel-space implementation, but also due to its close
> 
> Same comment about “its” as in the abstract: please replace “its”
> with what
> you’re talking about, as it isn’t clear.

changed to "kernel-space dependencies of HIP".

Thanks for your comments!
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Magnus,

pe, 2020-04-03 kello 09:17 +, Magnus Westerlund kirjoitti:
> > 
> > > 2. Secondly, as this solution is different from the RFC 5770
> should
> > > this
> > > solution have a different service name? The reason I am asking is
> > > that it
> > > depends on how for example how an initiator determine which of
> the
> > > NAT
> > > traversal solution. If there is any intention to use DNS SRV for
> > > example
> > > different service name would make sense. This is primarily to
> verify
> > > that this
> > > has been considered.
> > 
> > I am not an expert on the topic but based on some discussions with
> some
> > colleagues, the SRV records seem to more suitable for
> infrastructure
> > discovery, not really for end-host discovery. Since you asked for
> this,
> > I wrote a new section in the appendix:
> 
> So the main reason for my question was to ensure that you have not
> forgoetten
> that you actually have some dependnecy on the service name that would
> in fact be
> incompatible. That could include some supporting document, for
> example usage of
> SRV records. However, with the below text written, I do find it
> informative. And
> the statement at the end that you don't use SRV records currently is
> also good
> and part to answer one aspect of my question. To conclude, it appears
> to be no
> issues with having the two mechanisms share service name and port. 
> 
> From my perspective it appears to be some benefit in including the
> below
> appendix in the specificaiton, but you should seek consensus on it in
> the WG
> before the document is approved in my opinion.

I have sent an separate email to the WG mailing list on this.

P.S. Thanks for all of your valuable comments!
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

[Hipsec] DNS considerations in draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

during IESG review Magnus Westerlund asked about DNS support in draft-
ietf-hip-native-nat-traversal, so I added the the text below to draft-
ietf-hip-native-nat-traversal. Does it seem ok for the WG?

Appendix E.  DNS Considerations

[RFC5770] did not specify how an end-host can look up another end-
host via DNS and initiate an UDP-based HIP base exchange with it, so
this section makes an attempt to fill this gap.

[RFC8005] specifies how an HIP end-host and its Rendezvous server is
registered to DNS.  Essentially, the public key of the end-host is
stored as HI record and its Rendezvous Server as A or  record.
This way, the Rendezvous Server can act as an intermediary for the
end-host and forward packets to it based on the DNS configuration.
Control Relay Server offers similar functionality as Rendezvous
Server, with the difference that the Control Relay Server forwards
all control messages, not just the first I1 message.

Prior to this document, the A and  records in the DNS refer
either to the HIP end-host itself or a Rendezvous Server [RFC8005],
and control and data plane communication with the associated host has
been assumed to occur directly over IPv4 or IPv6.  However, this
specification extends the records to be used for UDP-based
communications.

Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this
document.  The Initiator looks up the FQDN of a Responder, and
retrieves its HI, A and  records.  Since the default policy is to
use UDP encapsulation, the Initiator MUST send the I1 message over
UDP to destination port 10500 (either over IPv4 in the case of a A
record or over IPv6 in the case of a  record).  It MAY send an I1
message both with and without UDP encapsulation in parallel.  In the
case the Initiator receives R1 messages both with and without UDP
encapsulation from the Responder, the Initiator SHOULD ignore the R1
messages without UDP encapsulation.

The UDP encapsulated I1 packet could be received by three different
types of hosts:

1.  HIP Control Relay Server: in this case the A/ records refers
to a Control Relay Server, and it will forward the packet to the
corresponding Control Relay Client based on the destination HIT
in the I1 packet.

2.  HIP Responder supporting UDP encapsulation: in this case, the the
A/ records refers to the end-host.  Assuming the destination
HIT belongs to the Responder, it receives and processes it
according to the negotiated NAT traversal mechanism.  The support
for the protocol defined in this document vs [RFC5770] is
dynamically negotiated during the base exchange.  The details are
specified in Section 4.3.

3.  HIP Rendezvous Server: this entity is not listening to UDP port
10500, so it will drop the I1 message.

4.  HIP Responder not supporting UDP encapsulation: the targeted end-
   host is not listening to UDP port 10500, so it will drop the I1
   message.

The A/-record MUST NOT be configured to refer to a Data Relay
Server unless the host in question supports also Control Relay Server
functionality.

It also worth noting that SRV records are not employed in this
specification.  While they could be used for more flexible UDP port
selection, they are not suitable for end-host discovery but rather
would be more suitable for the discovery of HIP-specific
infrastructure.  Further extensions to this document may define SRV
records for Control and Data Relay Server discovery within a DNS
domain.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Magnus,

pe, 2020-04-03 kello 09:49 +, Magnus Westerlund kirjoitti:
> Hi, 
> 
> See below.
> 
> On Fri, 2020-04-03 at 06:41 +0000, Miika Komu wrote:
> > Hi Magnus,
> > 
> > to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti:
> > > 
> > > > 4. MTU impact of NAT traversal.
> > > > 
> > > > Section 5.1 states
> > > > "It is worth noting that UDP encapsulation of HIP packets
> > > > reduces
> > > > the
> > > >Maximum Transfer Unit (MTU) size of the control plane by 12
> > > > bytes."
> > > > 
> > > > There is also a similar text in Section 5.11:
> > > > 
> > > >It is worth noting that UDP encapsulation of ESP reduces the
> > > > MTU
> > > > size
> > > >of data plane by 8 bytes.
> > > > 
> > > > I think the document needs a discussion and impact on MTU which
> > > > this
> > > > NAT
> > > > traversal has on the HIP packets being sent. - First of all
> > > > there
> > > > appears to be
> > > > more packet expansions happening in some cases, for example the
> > > > RELAY_HMAC
> > > > option expands packets on one leg. - Secondly, HIP requires IP
> > > > fragementation
> > > > support, however IP fragmentation through NAT is commonly not
> > > > working. Thus an
> > > > HIP packet being UDP encapsulated that results in packet
> > > > exceeding
> > > > MTU will
> > > > likely end up in an MTU black hole on path.
> > > > 
> > > > The addition of the NAT traversal encapsulation actually
> > > > increases
> > > > the need for
> > > > MTU discovery or care in MTU handling by the HIP initiator. I
> > > > think
> > > > there need
> > > > to be discussion of that in the document.
> > > 
> > > I am stil iterating some text on this, I hope Jeff Ahrenholz can
> > > help
> > > with this.
> > 
> > I got text from Jeff Ahrenholz and Robert Moskowitz:
> > 
> > Section 5.2
> > 
> > replaced this:
> > 
> > It is worth noting that UDP encapsulation of HIP packets reduces
> > the
> > Maximum Transfer Unit (MTU) size of the control plane by 12 bytes.
> > 
> > with:
> > 
> > UDP encapsulation of HIP packets reduces the Maximum Transfer Unit
> > (MTU) size of the control plane by 12 bytes (8-byte UDP header plus
> > 4-byte zero SPI marker), and the data plane by 8 bytes.  This
> > encapsulation overhead increases the need for MTU discovery.  A HIP
> > host SHOULD have the option to enable ICMP path MTU discovery
> > (PMTUD)
> > [RFC1063] [RFC8201].  Otherwise, support for IP fragmentation is
> > required, which may not be commonly supported through NATs.  When
> > HIP
> > encapsulation is implemented using a virtual tunneling interface,
> > consider using a reduced MTU (e.g. 1400) by default.  Additional
> > HIP
> > relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP,
> > etc., further increase the size of certain HIP packets.  It is
> > worth
> > noting that further HIP extensions can trim off 8 bytes in the ESP
> > header by negotiating implicit IV support in the ESP_TRANSFORM
> > parameter as described in [RFC8750].
> > 
> > Does this address your concerns?
> 
> I think the recommendation for virtual interface is a reasonable one
> based on
> the constraints. However, I think: 
> 
> A HIP
> > host SHOULD have the option to enable ICMP path MTU discovery
> > (PMTUD)
> > [RFC1063] [RFC8201].  Otherwise, support for IP fragmentation is
> > required, which may not be commonly supported through NATs.
> 
> maybe should be reformulated. ICMP messages are sometimes dropped in
> NATs,
> despite recommendations to support at least the TOO BIG messages. And
> I think if
> ICMP either is not working or not enabled, indicating that IP
> fragmentation
> could be a possible way to get thingst to work, appears even less
> likely to work
> as IP fragmentation handling in NATs becomes resource demanding due
> to all per
> packet state needed to be maintained, as only the first fragement
> contains the
> UDP header allowing the lookup of the translation record. 
> 
> Maybe it can be made clearer by restructuring the text so that it
> says this: 
> 
> - A HIP host SHOULD implement ICMP message handling to support MTU
> discovery per
> [RFC1063] 

Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Magnus,

to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti:
> 
> > 4. MTU impact of NAT traversal.
> > 
> > Section 5.1 states
> > "It is worth noting that UDP encapsulation of HIP packets reduces
> > the
> >Maximum Transfer Unit (MTU) size of the control plane by 12
> > bytes."
> > 
> > There is also a similar text in Section 5.11:
> > 
> >It is worth noting that UDP encapsulation of ESP reduces the MTU
> > size
> >of data plane by 8 bytes.
> > 
> > I think the document needs a discussion and impact on MTU which
> > this
> > NAT
> > traversal has on the HIP packets being sent. - First of all there
> > appears to be
> > more packet expansions happening in some cases, for example the
> > RELAY_HMAC
> > option expands packets on one leg. - Secondly, HIP requires IP
> > fragementation
> > support, however IP fragmentation through NAT is commonly not
> > working. Thus an
> > HIP packet being UDP encapsulated that results in packet exceeding
> > MTU will
> > likely end up in an MTU black hole on path.
> > 
> > The addition of the NAT traversal encapsulation actually increases
> > the need for
> > MTU discovery or care in MTU handling by the HIP initiator. I think
> > there need
> > to be discussion of that in the document.
> 
> I am stil iterating some text on this, I hope Jeff Ahrenholz can help
> with this.

I got text from Jeff Ahrenholz and Robert Moskowitz:

Section 5.2

replaced this:

It is worth noting that UDP encapsulation of HIP packets reduces the
Maximum Transfer Unit (MTU) size of the control plane by 12 bytes.

with:

UDP encapsulation of HIP packets reduces the Maximum Transfer Unit
(MTU) size of the control plane by 12 bytes (8-byte UDP header plus
4-byte zero SPI marker), and the data plane by 8 bytes.  This
encapsulation overhead increases the need for MTU discovery.  A HIP
host SHOULD have the option to enable ICMP path MTU discovery (PMTUD)
[RFC1063] [RFC8201].  Otherwise, support for IP fragmentation is
required, which may not be commonly supported through NATs.  When HIP
encapsulation is implemented using a virtual tunneling interface,
consider using a reduced MTU (e.g. 1400) by default.  Additional HIP
relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP,
etc., further increase the size of certain HIP packets.  It is worth
noting that further HIP extensions can trim off 8 bytes in the ESP
header by negotiating implicit IV support in the ESP_TRANSFORM
parameter as described in [RFC8750].

Does this address your concerns?

Btw, I would remove the following redundant statement in
"RELAYED_ADDRESS and MAPPED_ADDRESS Parameters" section:

It is worth noting that UDP encapsulation of ESP reduces
the MTU size of data plane by 8 bytes.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Magnus,

to, 2020-03-05 kello 03:08 -0800, Magnus Westerlund via Datatracker
kirjoitti:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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:
> ---
> ---
> 
> So I think the below are important things that needs to be discussed
> before
> proceeding. However, I might have missed things as I didn't have time
> to read
> the whole document in detail. Several of the issues are pieces for
> discussion
> to ensure that the right thing really is done.
> 
> 1. So this document recommends the usage of port 10500 as default
> listening
> port. A port registered by Ari and also used for RFC 5770. I get the
> impression
> that the port was registered separately from RFC 5770. So the port is
> assigned
> to Ari. Would Ari be willing to release the port for re-assignment to
> IESG
> control. RFC 6335 has the recommendation for ports for IETF protocols
> that the
> assignee is IESG and the contact ch...@ietf.org. This to have the
> change
> control with IETF as body rather than with individuals.
> 
> If Ari agrees to this, I think it would be good to have the IANA
> section be
> updated to note the re-assignment and provide the necessary
> information.

This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
plane and data plane traffic.  The port was was registered 
separately for RFC5770 to co-author Ari Keranen but should now be re-
assigned for IESG control.  With the permission of Ari Keranen, the new
assignee is IESG and contact "ch...@ietf.org".  In addition, IANA is
requested to add a reference to this document in the entry for UDP port
10500 in the Transport Protocol Port Number Registry.  The selection
between Legacy ICE-HIP and Native ICE-HIP mode is negotiated using
NAT_TRAVERSAL_MODE parameter during the base exchange.  By default,
hosts listen this port for incoming UDP datagrams and can use it also
for sending UDP datagrams.  Other emphemeral port numbers are
negotiated and utilized dynamically.

> 2. Secondly, as this solution is different from the RFC 5770 should
> this
> solution have a different service name? The reason I am asking is
> that it
> depends on how for example how an initiator determine which of the
> NAT
> traversal solution. If there is any intention to use DNS SRV for
> example
> different service name would make sense. This is primarily to verify
> that this
> has been considered.

I am not an expert on the topic but based on some discussions with some
colleagues, the SRV records seem to more suitable for infrastructure
discovery, not really for end-host discovery. Since you asked for this,
I wrote a new section in the appendix:

Appendix E.  DNS Considerations

[RFC5770] did not specify how an end-host can look up another end-
host via DNS and initiate an UDP-based HIP base exchange with it, so
this section makes an attempt to fill this gap.

[RFC8005] specifies how an HIP end-host and its Rendezvous server is
registered to DNS.  Essentially, the public key of the end-host is
stored as HI record and its Rendezvous Server as A or  record.
This way, the Rendezvous Server can act as an intermediary for the
end-host and forward packets to it based on the DNS configuration.
Control Relay Server offers similar functionality as Rendezvous
Server, with the difference that the Control Relay Server forwards
all control messages, not just the first I1 message.

Prior to this document, the A and  records in the DNS refer
either to the HIP end-host itself or a Rendezvous Server [RFC8005],
and control and data plane communication with the associated host has
been assumed to occur directly over IPv4 or IPv6.  However, this
specification extends the records to be used for UDP-based
communications.

Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this
document.  The Initiator looks up the FQDN of a Responder, and
retrieves its HI, A and  records.  Since the default policy is to
use UDP encapsulation, the Initiator MUST send the I1 message over
UDP to destination port 10500 (either over IPv4 in the case of a A
record or over IPv6 in the case of a  record).  It MAY send an I1
message both with and without UDP encapsulation in parallel.  

Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)

[Miika Komu]

Hi Mirja,

ke, 2020-02-26 kello 09:11 -0800, Mirja Kühlewind via Datatracker
kirjoitti:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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 my discuss points and most of my other
> comments. I
> believe the following comments from my previous ballot are still
> valid:
> 
> I agree with other ADs that it is not clear to me why this mechanism
> is needed
> in addition RFC5770. This is a use case for ICE and I would think
> that re-using
> existing code and library would make implementation easier, faster
> and less
> error-prone. I especially agree to the comments from Adam!

I have argumented this in earlier discussions, so I won't repeat it
here. Adam changed his ballot to "No objection".

> Other comments:
> 
> 4) sec 4.8: "When a host does not receive
>acknowledgments, e.g., to an UPDATE or CLOSE packet after a
> timeout
>based on local policies, a host SHOULD resend the packet through
> the
>associated Data Relay Server of the peer (if the peer listed it in
>its LOCATOR_SET parameter in the base exchange."
> I did not really find anything about this in section 5.10 of RFC5770.
> In think
> the timeout needs to be further specified.

the timeout mechanisms are specified in the RFC7401 state machine
specification, so I added a reference there instead of repeating it
here:
   A. 
   When a host does not receive acknowledgments, e.g., to an UPDATE or
   CLOSE packet after a timeout based on local policies, a host SHOULD
   resend the packet through the associated Data Relay Server of the 
   peer (if the peer listed it in its LOCATOR_SET parameter in the base
   exchange *according the rules specified in section 4.4.2 in
   [RFC7401]*.

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

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

[Miika Komu]

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.

Re: [Hipsec] Adam Roach's No Objection on draft-ietf-hip-native-nat-traversal-30: (with COMMENT)

[Miika Komu]

Hi Adam,

ma, 2020-02-24 kello 09:15 -0800, Adam Roach via Datatracker kirjoitti:
> Adam Roach has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-30: 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 to the authors for taking some of the concerns I laid out in
> my original
> ballot into account. I still do not believe this approach is good for
> HIP's
> benefit, but am no longer worried about collateral damage from other
> protocols
> imitating this approach. Accordingly, I am balloting "No Objection."
> 
> There is one remaining comment from my initial review that I think
> can and
> should be addressed prior to publication:
> 
> Appendix B:
> 
> >  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
> > protocol in order to avoid middlebox tampering.
> 
> This bullet should explain why such obfuscation is unnecessary.

based on discussion with Rescolarla, it actually says:

"Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol
but rather encrypted to avoid middlebox tampering."


https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-30#appendix-B

P.S. Thanks again for your time and effort in reviewing the document!
___
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,

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] Re-doing the IESG ballot for draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi Eric,

I disagree about the overhead occuring only during set up time because
STUN message format is incompatible with ESP formatting, so an
implementation needs to constantly monitor and intercept STUN packets
from the data-plane traffic. This causes a continuous overhead to the
data plane, so it is not only about set up time. Please check the draft
or hipsec mailing for more detailed discussion on this.

pe, 2020-02-21 kello 05:38 -0800, Eric Rescorla kirjoitti:
> I would like to note for the record that I do not find the arguments
> in the applicability statement at all persuasive. They are
> principally about performance but ICE occurs at setup time (so CPU
> performance is not much of an issue) and is inherently so, with
> pacing and RTT the dominant factors (and so the system architecture
> issues are unpersuasive). As I am no longer an AD, this is just
> opinion, but were I the AD,  I would insist on a strong rationale.
> 
> -Ekr
> 
> 
> On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) <
> evyn...@cisco.com> wrote:
> > Hi,
> >  
> > The first IESG ballot for the draft-ietf-hip-native-nat-traversal
> > was done in May 2018 and was blocked by a couple of DISCUSS by the
> > 2018 IESG. The main issue IMHO was around “why not reusing plain
> > ICE?”; the authors in discussion with Adam Roach have provided an
> > applicability statement and a justification on why “plain ICE” does
> > not work efficiently when combined with HIP + additional text or
> > replies for the remaining DISCUSS & COMMENT.
> >  
> > The diff are 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30=draft-ietf-hip-native-nat-traversal-28
> >  
> > I have reviewed all COMMENT and DISCUSS from 2 years ago and it
> > appears to me that they are all addressed (including those from
> > 2018 AD who are no more AD in 2020 – they are in cc). The changes
> > in the document are minor and I am confident that neither a WG Last
> > Call not an IETF Last Call is required. I am therefore placing the
> > document in the next IESG telechat and opening a new IESG ballot.
> >  
> > Thank you for the authors on their energy to keep the document
> > useful,
> >  
> > Regards,
> >  
> > -éric
> >  
> 
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
___
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)

[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)

[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)

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

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

[Miika Komu]

Hi Spencer,

thanks for your comments, please see my response below.

ke, 2018-05-09 kello 18:18 -0700, Spencer Dawkins kirjoitti:
> 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.

I am not sure exactly what you mean by middlebox provisioning, but at
least a couple of things have been clarified in the draft related to
middleboxes:

* STUN may be used for discovering address candidates; HIP Control
Servers are recommended 
* The address candidates are encrypted to protect against middlebox
tampering 

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

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

[Miika Komu]

Hi Ben,

thanks for your comments! My response below.

ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti:
> 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.

the current document has been organized for implementors of RFC5770 in
mind.

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

HIP WG decided to move all of its experimental work to standards track.

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

thanks, corrected.

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

boilerplate added. Please comment some specific lower-case keyword is
incorrect in your opinion.

> §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.

it is either adapted from ICE (by e.g. changing "agent" to "host" or
referencing the ICE spec (by sections). Based on the earlier reviews,
the text has evolved now into the following:

  The rules in section 5.1.1 in [RFC8445] for candidate gathering
are   followed here.  A number of host candidates (loopback, anycast
and   others) should be excluded as described in section 5.1.1.1 of the
ICE   specification [RFC8445].  Relayed candidates SHOULD be gathered
in   order to guarantee successful NAT traversal, and
implementations   SHOULD support this functionality even if it will not
be used in   deployments in order to enable it by software
configuration update if   needed at some point.  Similarly as explained
in section 5.1.1.2 of   the ICE specification [RFC8445], if an IPv6-
only host is in a network   that utilizes NAT64 [RFC6146] and DNS64
[RFC6147] technologies, it   may also gather IPv4 server- reflexive
and/or relayed candidates from   IPv4-only Control or Data Relay
Servers.  IPv6-only hosts SHOULD also   utilize IPv6 prefix discovery
[RFC7050] to discover the IPv6 prefix   used by NAT64 (if any) and
generate server-reflexive candidates for   each IPv6-only interface,
accordingly.  The NAT64 server-reflexive   candidates are prioritized
like IPv4 server-reflexive candidates.

> - paragraph 6: I'm confused in that I thought the previous text said
> that
> native ICE-HIP does not use STUN.

you mean paragraph 7?

   Gathering of candidates MAY also be performed by other means than
   described in this section.  For example, the candidates could be
   gathered as specified in Section 4.2 of [RFC5770] if STUN servers 
   are available, or if the host has just a single interface and no
   STUN or Data Relay Server are available.

Nothing prevents an implementation from gathering candidates via STUN
but the recommended way is HIP control Relay as the "MAY" indicates
here.

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

I have changed this now to a more precise statement:

   Since the control plane protocol and Control Relay Server are
   essentially the same (with some minor differences) in this document
   as in Legacy ICE-HIP [RFC5770], the same security considerations (in
   Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still
   valid, but are repeated here for the sake of completeness.  New
   security considerations related to the new Data Relay Server are
   discussed in Section 6.5, and considerations related to the new
   connectivity check protocol are discussed in Section 6.6 and
   Section 6.7 .

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

I changed to "for", I assume 

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

[Miika Komu]

Hi Alvaro,

ke, 2018-05-09 kello 13:44 -0700, Alvaro Retana kirjoitti:
> 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.

we have clarified the relationship in the latest version (as discussed
in our response to Benjamin). Hopefully this addresses also your
comments.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

[Miika Komu]

Hi Mirja,

thanks for your comments! My response is below, let me know if you have
further concerns.

to, 2018-05-10 kello 03:00 -0700, Mirja Kühlewind kirjoitti:
> Mirja Kühlewind 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:
> ---
> ---
> 
> 1) This document should also update the IANA port registry to add a
> reference
> to this RFC-to-be to the existing entry for port 10500 (eventually
> even with
> note that this RFC-to-be discusses how to distinguish the services
> using
> NAT_TRAVERSAL_MODE).

IANA section should describe this:

   This document reuses the same default UDP port number 10500 as
   specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
   plane and data plane traffic.  The selection between Legacy ICE-HIP
   and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE
   parameter during the base exchange.

Let me know if something needs to be added.

> 2) Sec 4.4: "Hosts SHOULD NOT use values smaller than 5 ms for the
> minimum
> Ta,..." In rfc5245bis this is a MUST. Why is this a SHOULD here?

Because it used to be like that in an earlier version of ICE. Good
catch, I have now changed SHOULD to MUST now.

> Also in sec 4.6.2.:
> "If neither one of the hosts announced a minimum pacing value, a
> value of 50 ms
> SHOULD be used." This must be a MUST to be inline with sec 4.4.

thanks, both are now "MUST"s.

> 3) Appendix A: "Ta value so that only two connectivity check messages
> are sent
> on every RTT." Why two? RFC8085 recommends (SHOULD) at may one packet
> per RTT
> for non-congestion control transmissions

aligned with RFC8085 as you requested:

 In this case, it is recommended that the hosts
   estimate the round-trip time (RTT) between them and SHOULD set the
   minimum Ta value so that at most a single connectivity check message
   is sent on every RTT.

> ---
> ---
> COMMENT:
> ---
> ---
> 
> I agree with other ADs that it is not clear to me why this mechanism
> is needed
> in addition RFC5770. This is a use case for ICE and I would think
> that re-using
> existing code and library would make implementation easier, fast and
> less-error-prone. I especially agree to the comments from Adam!

ICE was not designed with IPsec in mind, so the performance overhead is
unacceptable. I have also some additional reasoning for Adam Roach
here:


https://mailarchive.ietf.org/arch/msg/hipsec/Lx3SLQVaHI2ZKsMP8xxT27RMEn8

and here:


https://mailarchive.ietf.org/arch/msg/hipsec/tJ4evwlPEWOEHsRXLjFVlQS-ykE

> Other comments/nits:
> 
> 1) sec 4.6.2: "Upon successful nomination an address pair, a host MAY
> immediately stop sending such retransmissions." Not sure I understand
> this
> sentence; why MAY?

It should read "nomination *of* an address". I changed the MAY to
SHOULD:

Upon successful nomination of an
   address pair, a host MUST immediately stop sending such
   retransmissions.

> 2) sec 4.1: The registration to the Control Relay Server can be
> achieved using
>RELAY_UDP_ESP parameter as explained later in this section."
> I guess that should be RELAY_UDP_HIP?

good catch, corrected this.

> 3) sec 4.1: "It is RECOMMENDED that the Relay Client select a random
> port
> number..." Please say source port -> s/random port number/random
> source port
> number/

done!

> 4) sec 4.8: "When a host does not receive
>acknowledgments, e.g., to an UPDATE or CLOSE packet after a
> timeout
>based on local policies, a host SHOULD resend the packet through
> the
>associated Data Relay Server of the peer (if the peer listed it in
>its LOCATOR_SET parameter in the base exchange."
> I did not really find anything about this in section 5.10 of RFC5770.
> In think
> the timeout needs to be further specified.

section 4.8 is "Sending Control Packets after the Base Exchange". Do
you mean section 4.10 in RFC57700:

https://tools.ietf.org/html/rfc5770#section-4.10

...which is also suggests "timeout based on local policies".

> 5) sec 5.3: "It is worth noting that sending of such a HIP NOTIFY
>message MAY be omitted if the host is actively (or passively)
> sending
>some other traffic (HIP or ESP) "
> This should really be a SHOULD (at least).

agreed, 

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

[Miika Komu]

Hi Alissa,

ke, 2018-05-09 kello 08:39 -0700, Alissa Cooper kirjoitti:
> Why is this document on the standards track when RFC 5770 was
> experimental?

I forgot to explain this. The reason was that the WG decided to push
all of the experimental track work to standards track, including the
earlier experimental RFC 5770 which is now draft-ietf-hip-native-nat-
traversal.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

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

[Miika Komu]

Hi Alissa,

thanks for the comments. Let me know if you have further concerns, my
corrections are listed below.

ke, 2018-05-09 kello 08:39 -0700, Alissa Cooper kirjoitti:
> 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?

Eric Rescolarla commented about this first, so this text will be
removed in the next version. The new text actually mandates encrypted
locators:

With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated
within an ENCRYPTED parameter (denoted here with ENC) according to the
procedures in sections 5.2.18 and 6.5 in [RFC7401].

Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol
but rather encrypted to avoid middlebox tampering.

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

It is actually better to expose all IP addresses because the host may
not necessarily have adequate knowledge of the (possibly cascading) NAT
topologies and whether the other peer is in "intra" or "extra" network
and so on. Still, I think we should not mandate exposing all network
interfaces in cases where the host knows the topology and there are
some privacy concerns. So to better reflect your comment, I changed the
text as follows:

For these two local policy reasons, an end-host MAY exclude certain
host addresses from its LOCATOR_SET parameter, but this requires
further experimentation.

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

I have removed "that" so it should make more sense now:

   To overcome this problem, different methods, commonly referred to as
   NAT traversal techniques, have been developed.

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

> = Section 2 =
> 
> The paragraph about RFC2119 should also reference RFC8174.

I changed the wording as follows:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

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

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

[Miika Komu]

Hi Benjamin,

thanks for the very detailed comments and apologies for my extremely
slow reaction! My corrections are below. If you think I haven't
addressed your concerns, please let me know.

ke, 2018-05-09 kello 08:02 -0700, Benjamin Kaduk kirjoitti:
> 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.

as discussed in earlier reviews, I have already added some text to the
introduction:

HIP poses a unique challenge to using standard ICE, due not
only to its kernel-space implementation, but also due to its
close integration with kernel-space IPSec; and, that while RFC5770"
provides a technically workable path, it incurs
unacceptable performance drawbacks for kernel-space
implementations. Also, implementing and integrating a full
ICE/STUN/TURN protocol stack as specified
in Legacy ICE-HIP results in a considerable amount of effort and
code which could be avoided by re-using and extending HIP
messages and state machines for the same purpose. [...]
The differences to the Legacy ICE-HIP are further elaborated in Section
[...]

As requested by your, I updated the last sentence of the abstract as
follows:

The main difference from the previously specified modes is the use of
HIP messages instead of ICE for all NAT traversal procedures due to its
kernel-space dependencies.

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

RFC8445 mentions "offer/answer" as an example but I agree it is more of
an SDP terminology. The offer/answer + nat traversal procedures are
coupled into a single control plane (=HIP), hence we are combining
terminology from both the specifications. I updated the terminology a
bit to reflect your comments better:

   HIP offer:
  Before two end-hosts can establish a communication channel using
  the NAT traversal procedures defined in this document, they need
  exchange their locators (i.e. candidates) with each other.  In
  ICE, this procedure is called Candidate Exchange and it does
  specify how the candidates are exchanged but Session Description
  Protocol (SDP) "offer/answer" is mentioned as an example.  In
  contrast, the Candidate Exchange in HIP is the base exchange
  itself or a subsequent UPDATE prodecure occurring after a
  handover.  Following [RFC5770] and Session Description Protocol
  (SDP) [RFC3264] naming conventions, "HIP offer" is the the
  Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE
  control packet.

   HIP answer:
  The Responder's LOCATOR_SET parameter in a HIP R2 control packet.
  Corresponds to the SDP answer parameter [RFC3264], but is HIP
  specific.  Please refer also to the longer description of the 
  "HIP offer" term above.

> 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 

Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt

[Miika Komu]

Hi,

ke, 2020-02-12 kello 17:20 +, Jeff Ahrenholz kirjoitti:
> > I believe this version answers all the IESG issues.
> > 
> > Please review, there are some important additions.
> > 
> > EKR had a number of security concerns.  Some I feel don't apply to
> > HIP, like use an AEAD for HIP packet security.
> > 
> > But there are a number of added sections, particularly in Security
> > Considerations that are worth the group's review that I have things
> > stated properly.
> > 
> > Also there is a new parameter, I_NONCE to add Initiator randomness
> > into the Master Key generation.  There is some cleanup in the
> > KEYMAT section to reflect this.
> > 
> > So please take a read through.
> 
> I took a look at the new I_NONCE parameter...
> 
> Regarding this statement (Section 5.2.6):
> "The I_NONCE parameter encapsulates a random value that is later used
> in the Master key creation process (see Section 6.3)."
> 
> Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using
> Diffie-Hellman derived key Kij, but I don't see anything about using
> I_NONCE. There is a random #I  provided by the Responder from the
> PUZZLE parameter, but nothing about a random I_NONCE supplied by the
> Initiator.

thanks for catching this! This occurred due to a html comment inside a
figure (xml2rfc team is working on a fix). Here is the fixed document:

https://tools.ietf.org/html/draft-ietf-hip-dex-13#section-6.3

> minor nits:
> s/when key is smaller or equal to 128 bits/when the key is smaller or
> equal to 128 bits/
> In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to
> RFC 7401 sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the
> dex draft.

apparently this has to be fixed manually in collaboration with the RFC
editor.
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11

[Miika Komu]

Hi,

(Robert, please double check if you agree with my comments)

su, 2019-11-24 kello 22:38 -0800, Michael Richardson via Datatracker
kirjoitti:
> Reviewer: Michael Richardson
> Review result: Ready
> 
> I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex
> I reviewed the -11 version.
> 
> I did not identify any technical problems or gaps.
> The introduction tells that I won't understand this without a good
> understanding of RFC7401 (HIPv2).  I went ahead anyway, given that I
> did know
> HIPv1 (RFC5201) and IKEv2.
> 
> While it is clear that I could not implement without knowing 7401, I
> did find
> that I could understand most of the goals, the compromises that were
> made to
> reduce the complexity for constrained environments.  I did go back
> and read
> 7401 in the end to fill in a few gaps.
> 
> Particularly I really needed to understand RFC7343 HITs of the new
> type, and
> I did not manage to understand that part.

let us know if we should clarify something particular in the DEX draft.

> I observe that a new ECDH type of
> HIT is defined, but I did understand how these values would be
> exchanged/stored or looked up.
> I would appreciate a use case or two which has been sufficiently
> built-out so
> that I can see the whole picture. If ECDH HITs come from DNS (via
> 
> records) for instance, then I'd appreciate an understanding if/how
> the
> constrained device is able to leverage DNSSEC.

not really  records, but rather "HI" records, so actually the
public key is stored in the DNS as defined in RFC8005.

Nothing prevents using DNSSEC except the capabilities of the device. I
don't know the footprint of a minimal DNSSEC implementation at the
client side...

> In particular, I'd like to know what kind of applications are ruled
> out by
> lack of PFS,

this is a rather generic question and I don't know if some researched
and created a taxonomy of applications that fit PFS. So I don't really
have a good answer for this but just a couple of easy answers:

* If the data is of emphemeral nature (useful only at the very
present), then PFS may not be necessary.
* If the hardware too is too constrained, then non-PFS security is
better than no security.

> and if a kind of PFS can be restored by rotating HITs in DNS.

really interesting, how would this work in practice?

(Usually it's just the server's HITs stored in the DNS so perhaps just
extra security measure for the server?)

> Would this document play well with draft-ietf-ipsecme-implicit-iv?

BEX and DEX can be used with any data plane security, but ESP is
commonly used, so I don't really see why not. Saving bits on the wire
for the data plane in contrained scenarios is always good.

Robert what do you think?

> I am unclear if the diet nature of DEX is more about:
>   (1) constrained/challenged networks
>   (2) constrained/slow CPUs
>   (3) systems with very minimal amounts of flash

I haven't been involved with this work since the beginning, so perhaps
Robert should comment on this more but here's my interpretation. I
believe the priority is on slow CPUs and flash comes as the second.
Network is the last one in the priority list; if you check the origins
of the work, for instance, the "Slimfit" approach compresses HIP
messages much better.

RFC7228 section 3 lists different classes of IoT devices but it's
mostly related to the memory dimension. I am not sure if have
classifications for the network/CPU dimensions in IETF...

> (1) networks have often very small packet sizes, and I would
> appreciate
> understanding the total frame sise of each I1/R1/I2/R2, and any
> impact that
> fragment assembly might have on the statelessness of the I1/R1
> exchange.

according to Hummen et al, "Slimfit - A HIP DEX Compression Layer
for the IP-based Internet of Things", DEX packets sizes were roughly as
follows in an earlier version of the draft (draft-moskowitz-hip-dex-
00):

I1: 48 bytes
R1: ~184 bytes
I2  ~232 bytes
R2: ~86 bytes

> I know that HIP has be profiled for use in 802.15.9, and I assume
> that HIP
> DEX is even better, but the lack of PFS might be a show stopper.

Quoting Eric Vyncke:

"I had a conversation with Ben Kaduk today at the hackathon. While Ben
had reviewed the DEX document about 2 years ago, he was clear that PFS
is a requirement for IETF standard _EXCEPT_ (and this is important):
1) the text is clear that there is no PFS property in DEX
2) there is a justification why PFS was not implemented (such as
defining a specific use case)."

Regarding to the use case, Robert sent the following text proposal
earlier:

HIP DEX, by design does not support Perfect Forward Secrecy (PFS). All 
current PFS approaches use Ephemeral DH, secured and identified in
some  manner (e.g. SIGMA or PAKE).  There are classes of devices, like
those  based on the 8051 microprocessor where this is prohibitably
expensive.   Experience with the ZWAVE ZW0500 found that EC25519 key
pair generation  exceeded 10 seconds with unacceptable battery

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

[Miika Komu]

Hi,

pe, 2019-10-04 kello 10:58 -0500, Adam Roach kirjoitti:
> Thanks for the reply! I think we're getting closer to an answer
> here, 
> but I'm still quite lost on one key aspect.
> 
> 
> On 10/4/19 7:15 AM, Miika Komu wrote:
> > In the legacy HIP NAT traversal (RFC5770), we have third protocol
> > (STUN) on the same port and it does not follow RFC7401 conventions
> > because it was not designed with IPsec in mind. As a result,*all*
> > packets need to be diverted to an userland daemon in order to
> > separate
> > the STUN packets from HIP/ESP.
> 
> 
> I can't figure out why this diversion is necessary. What prevents 
> characterization of packets in kernel space?

so let's split discussion of a new kernelspace component into
subproblems below. I believe the security aspects (2) could be real a
showstopper.

1. Standardization

I believe separate separate standardization effort (RFC2367?) would be
needed since this would impact all IPsec keying daemons, not just HIP
(since they share the kernel). I am not sure how to do it because
PF_KEY API is not really meant for delivering entire STUN packets to
userland daemons.

2. Security

Some security considerations are also needed to avoid messing ESP
traffic with bogus STUN packets. Probably this can be a big mess
because STUN packets don't have as strong security measures as
IKE/HIP/etc IPsec keying daemons.

Possibly STUN message security checks needs additional inspection via
userspace daemons, which makes a kernelspace solution moot.

3. Performance overhead

The kernelspace component would have to be some kind of hook in the ESP
modules (at least in the tunnel and beet modules) that detects incoming
STUN and deliver it to userspace daemons. It would still incur some
performance overhead since all ESP packets need extra inspection
(albeit incur less overhead than with userspace diversion).

4. Other IPsec keying daemons

A new ESP extension would require extra support in all existing IPsec
keying daemons since it's a new kernel module impacting all of them. It
doesn't make sense to define just a single hack for HIP.

5. Ship the kernelspace extension as a standard Linux kernel module

Have you ever implemented a Linux kernel module and tried to get it
accepted into Linux kernel? We actually tried to get HIP control plane
into Linux networking stack and failed miserably. Then we changed plans
and struggled a couple of years with the BEET IPsec module and finally
got it into Linux kernel. It was worth the trouble but personally I'd
rather not repeat this exercise again.

6. Ship the kernelspace extension as a separate kernel module

One option is to maintain a separate kernel module like with Virtual
Box or VMware has been doing earlier. So when you install HIP software,
you need to compile a kernel module. This is ok for developers, but I
don't think normal users want to do it. And it is painful to do it
everytime you have kernel updates, so you really want to have your
stuff in Linux distributions (of which there are quite a many...)

7. Repeat the exercise with Apple and Windows

No idea what it requires.

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

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

[Miika Komu]

 misunderstanding some
> subtle
> aspect of the way these protocols interact with each other, but isn't
> this
> described performance impact simply the result of specific
> implementation
> design decisions rather than inherent to the design of RFC 5570's
> mechanism?

the userspace diversion is completely unnecessary in the native NAT
traversal draft. HIP control packets have a special encoding following
RFC7401 conventions that allows the IPsec kernel module to pass the
non-ESP packets to userspace (i.e. to HIP userspace dameon). ESP
packets do *not* need any diversion.

In the legacy HIP NAT traversal (RFC5770), we have third protocol
(STUN) on the same port and it does not follow RFC7401 conventions
because it was not designed with IPsec in mind. As a result, *all*
packets need to be diverted to an userland daemon in order to separate
the STUN packets from HIP/ESP. All packets means also the data
plane,i.e., ESP data packets...

I spent half a day to find legacy HIP ICE measurements from around 20
master theses and publications. Unfortunately, I did not find exact
match but I would argue that the so called LSI translation has a
similar overhead as parsing the STUN packets. Based on the peer reviwed
publication below, dealing with STUN (or LSI) with userspace daemon and
iptables-queue target has roughly 40 % performance penalty on latency
and 12 % penalty on throughput (with TCP traffic). So the impact on
latency is IMHO unacceptable.

Lirim Osmani, Salman Toor, Miika Komu, Matti J. Kortelainen, Tomas
Lindén, John White,
Rasib Khan, Paula Eerola, Sasu Tarkoma, "Secure Cloud Connectivity for
Scientific Applications",
special issue on Cloud Services Meet Big Data of the IEEE Transactions
on Services Computing, 2015

> >  Also, relaying of ESP packets via TURN relays was not
> >  considered that simple because TURN relays require adding and
> >  removing extra TURN framing for the relayed packets.
> 
> While it's been a while since I've looked at network kernel code, my
> recollection is that implementation of the POSIX "sendmsg()" system
> call
> generally maintains scatter/gather buffers all the way down the stack
> until
> such bytes are copied from system memory to the network hardware.
> Stripping
> such headers on receipt can be accomplished with simple pointer
> arithmetic.
> It's not clear what aspect of the system "simple" is intended to
> refer to, but
> both implementation and performance impacts should be immeasurably
> small when
> implemented in this way, unless I'm missing something.

The extra TURN framing means that there will be extra context switching
at the endpoints because it needs to be handled in the userspace
(=additional latency, lower bandwidth, smaller MTU).

With an ESP relay (as specified in native NAT traversal) you don't need
any framing at all and all the ESP processing can be done as if no
relay was used.

> >  Finally, the developers of the two Legacy ICE-HIP implementations
> > concluded
> >  that "effort needed for integrating an ICE library into a HIP
> >  implementation turned out to be quite a bit higher that initially
> >  estimated.  Also, the amount of extra code (some 10 kLoC) needed
> > for all
> >  the new parsers, state machines, etc., is quite high and by re-
> > using the
> >  HIP code one should be able to do with much less.  This should
> > result in
> >  smaller binary size, less bugs, and easier debugging.".
> 
> Such size is not inherent in the implementation of ICE: for example,
> the ICE
> stack used by Firefox is 2.2 kLoC in size (if you ignore the ~1.2
> kLoC of
> boilerplate copyright notice). Having seen the debugging of an ICE
> stack
> up-close-and-personal, I'm pretty comfortable saying that the effort
> to
> integrate a working stack has to be orders of magnitude less than
> implementing
> even the simplified ICE procedures defined in this document
> correctly. There
> are a lot of surprising corner cases that don't really turn up until
> you get
> into production.

surely, the corner cases are documented in the ICE specification for
new ICE implementations.

> For the foregoing reasons, it is my conclusion that publication of
> this
> document is harmful for HIP and is harmful as a precedent that other
> protocols
> may mistakenly emulate. I believe that a restructuring of the
> document to more
> clearly explain why HIP chose this path while other protocols should
> not would
> limit some of these concerns. However, I do not believe that the
> fundamental
> flaw -- a partial respecification of ICE for the cited reasons
> --  can be
> fixed. I do not support publication of a document describing this
> mechanism,
> and encourage the working group to withdraw the docume

Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)

[Miika Komu]

Hi,

ma, 2018-05-21 kello 17:52 -0700, Spencer Dawkins kirjoitti:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-hip-dex-06: 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-dex/
> 
> 
> 
> ---
> ---
> COMMENT:
> ---
> ---
> 
> I'm not an expert on what people expect about security, but I'm
> wondering if
> there's a little too much distance between this text in the Abstract,
> 
>   This document specifies the Host Identity Protocol Diet EXchange
> (HIP
>DEX), a variant of the Host Identity Protocol Version 2
> (HIPv2).  The
>HIP DEX protocol design aims at reducing the overhead of the
> employed
>cryptographic primitives by omitting public-key signatures and
> hash
>functions.  In doing so, the main goal is to still deliver similar
>security properties to HIPv2.
> 
> and this text in the Introduction,
> 
>   The main differences between HIP BEX and HIP DEX are:
> 
> (snip)
> 
>   2.  HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of
>HIPv2 due to the removal of the ephemeral Diffie-Hellman key
>agreement.
> 
> Would the average reader consider "no PFS" to be similar to PFS?
> (Please note that I'm not questioning the choice made in DIX, only
> the way that
> choice is described in the Abstract)

I agree that "similar" is very ambiguous. I have removed the sentence
"In doing so, the main goal is to still deliver similar security
properties to HIPv2" from the abstract (as suggested offline by Eric
Vyncke). I hope this resolves your comment?

> I'm curious about whether a couple of other differences named in the
> Introduction would also qualify as similar, but let's start with PFS.
> 
> I'm also curious about whether
> 
> 1.1.  The HIP Diet EXchange (DEX)
> 
> (snip)
> 
>HIP DEX does not have the option to encrypt the Host Identity of
> the
>Initiator in the 3rd packet.  The Responder's Host Identity also
> is
>not protected.  Thus, contrary to HIPv2, HIP DEX does not provide
> for
>end-point anonymity and any signaling that indicates such
> anonymity
>should be ignored.
> 
> qualifies as "similar", but I don't have a good sense of how much
> this matters
> in current and expected HIP deployments.

the sentence has been removed from the abstract, I hope this point is
also moot now.

> I'm hardly the smart one about this, but is
> 
>   o  HIP DEX lacks the Perfect Forward Secrecy (PFS) property of
> HIPv2.
>   Consequently, if an HI is compromised, all HIP connections
>   protected with that HI are compromised.
> 
> correct? I was expecting to see something like "if an HI is
> compromised, all
> previous HIP connections protected with that HI are compromised".

you are correct, fixed.

> The version of this draft I'm reviewing has 57 occurrences of the
> word
> "should". I'm not seeing very many cases where the surrounding text
> explains
> why an implementation would not do what it SHOULD do, and I'm not
> seeing many
> cases where the surrounding text explains what the peer
> implementation should
> do, if the other endpoint doesn't do what it SHOULD do, although many
> of those
> cases might be captured in the state diagrams in the document.

many of the SHOULDs are inherited from the text in RFC7401. If you
really want to, I can do a side by side comparison and check which ones
are really new, and then improve the new ones? With my current
priorities at work, this will unfortunately take a lot of time. Another
way to resolve your comment is to add some general statement about the
SHOULDs in the specification.

> In this text,
> 
>   By eliminating the need for public-key signatures and the ephemeral
>DH key agreement, HIP DEX reduces the computation, energy,
>  
>transmission, and memory requirements for public-key cryptography
>^
>(see [LN08]) in the HIPv2 protocol design.  Moreover, by dropping
> the
>cryptographic hash function, HIP DEX affords a more efficient
> 
>protocol implementation than HIP BEX with respect to the
>^^^
>corresponding computation and memory requirements.
> 
> is "efficient" the right word, in the second sentence? This seems to
> mirror
> that "reducing requirements" effect from the first sentence - I'd
> assume that
> if 

Re: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06

[Miika Komu]

Hi Qin,

I am stepping in and helping the authors to finalize this draft.

On 3/2/18 20:15, Robert Moskowitz wrote:
> 
> 
> On 02/23/2018 03:23 AM, Qin Wu wrote:
>> Reviewer: Qin Wu
>> Review result: Ready
>>
>> Summary:
>> This document defines the Host Identity Protocol Diet EXchange (HIP
>>     DEX) protocol for constrained devices. The draft is well written. 
>> I believe
>>     it is ready for publication.
>> Major issue: None
>> Minor issue: Editorial
>> 1.It is not clear how fine-grained policy control defined in IKEv2 is 
>> different
>> from policy control defined in HIP DEX protocol?
> 
> There is a long-standing difference in HIP to IKE policy.  I am 
> "shooting from the hip" a bit here, as it has been years since having 
> this sort of discussion.  For starters, HIP does not have policyu bound 
> to an interface IP address.  Then there is the nature of parameters in 
> HIP DEX like the size of the cookie puzzle and how in some IOT cases, 
> this can actually be used as an attack so policy may be used to manage 
> this.  Much is left to the implementer, it is true.

https://tools.ietf.org/html/rfc7401#section-1.2

"The base protocol does not cover all the fine-grained policy control
found in Internet Key Exchange (IKE) [RFC7296] that allows IKE to
support complex gateway policies.  Thus, HIP is not a complete
replacement for IKE."

>>   In the draft, local policies
>> are mentioned many times, however it is not clear what local policy 
>> for HIP DEX
>> Protocol looks like?
> 
> To this I have to defer to Rene, who has implemented DEX...

RFC7401 lists some things relevant to local policies:

https://tools.ietf.org/html/rfc7401#page-106

The relevant ones are repeated also in HIP DEX:

https://tools.ietf.org/html/draft-ietf-hip-dex-06#section-7

>>   Is it possbile to carry policy control parameters(e.g.,
>> ACL parameter) in the HIP DEX protocol message?
> 
> HIP has avoided negotiating policies, and thus carrying them in 
> messages.  I am working some drafts that does provide for limited policy 
> control parameters.

agree with Robert, ACLs are not carried in HIP messages.

 >> Would it be great to provide example to clarify this.

Section 7 lists policy examples (please check my earlier comment).

>> 2. Is Nonce I same as radom value #I?

yes, it is the same. I added to section 2.3. Definitions:

Nonce #I and #J:  Nonce #I and nonce #J refer to the corresponding
   fields in the PUZZLE parameter (see section 5.2.4 in [RFC7401].
   They are also referred as "random value #I and #J" in this
   document.

>> 3. Is puzzle difficulty K same as #K used in the HIP R1 described in section 
>> 7?

this is correct. I clarified in section 2.3 Definitions:

Puzzle difficulty K:  The Initiator has to compute a solution for the
   puzzle.  The level of computational difficulty is denoted by the
   #K field in the puzzle parameter (see section 5.2.4 in [RFC7401].

and section 7 (#K is now without the hash):

  The value of puzzle difficulty K used
in the HIP R1 must be chosen with care.  Values for the K that are
too high will exclude clients with weak CPUs because these devices
cannot solve the puzzle within a reasonable amount of time.  The K
value should only be raised if a Responder is under high load, i.e.,
it cannot process all incoming HIP handshakes any more.  If a
Responder is not under high load, K SHOULD be 0.

>> 4. Is puzzle difficulty K same as low-order #K bits of the RHASH?

no, K is the #K field in the puzzle parameter (as now clarified in the 
Definitions). It refers is the number of bits that should be zero when 
calculating the puzzle solution from the RHASH as mentioned in section 
5.3.3 in the DEX draft:

The low-order #K bits of the RHASH(I | ... | J) 

MUST be zero.

>> If the answer is 
>> yes, please make the term and symbol used in the draft consistent.
> 
> Good catch on this.  I will check this over.

I have now clarified the terms and their variants now in section 2.3, I 
hope this works for you?

Thanks for your comments and I hope this resolves your concerns!

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

Re: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06

[Miika Komu]

Hi David,

I am stepping in and helping the authors to finish the draft as agreed 
with the authors and HIP WG chair. I am not actively working on the 
topic, so I have very limited time for this but I have earlier 
background in HIP. Please let me know if the following comments and 
edits address your concerns?

On 2/23/18 04:01, David Waltermire wrote:
> Reviewer: David Waltermire
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area 
> directors.
>   Document editors and WG chairs should treat these comments just like any 
> other
> last call comments.
> 
> The summary of the review is Ready with issues.
> 
> In general this document is clearly-written and well-organized. It was a fun
> read overall.
> 
> I have the following concerns with the draft:
> ---
> 
> Section 2.1:
> 
> You should use text from RFC8174 to indicate that lowercase versions of the
> keywords are not normative.
> 
> Something like the following would work:
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> "OPTIONAL" in this document are to be interpreted as described in BCP
> 14 [RFC2119] [RFC8174] when, and only when, they appear in all
> capitals, as shown here.

fixed.

> Section 4.1.3.1:
> 
> "it can be long-lived with no need for rekeying" Small is open to
> interpretation. It would be useful to include some guidance on the expected
> amount of data to be exchanged before rekeying would be needed, or why this is
> a practical impossibility.

rekeying is subject to local policies, but a hard limit exists. I added 
the following sentence:

At the latest, the system MUST initiate
rekeying when its incoming ESP sequence counter is going to overflow,
and he system MUST NOT replace its keying material until the rekeying
packet exchange successfully completes as described in section 6.8 in
[RFC7402].

> Section 5.3.2 and 5.3.3:
> 
> In the paragraph on TRANSPORT_FORMAT_LIST, it would be good to document the
> specific ESP parameter value to be used from:
> https://www.iana.org/assignments/hip-parameters/hip-parameters.xml#transport-modes.
> This will remove any ambiguity.

I changed the sentence referring to the parameter value to be more specific:

The different format types are DEFAULT, ESP and ESP-TCP as explained in 
Section 3.1 in [RFC6261].

The actual choice(s) depend on local policy, I don't think we should 
mandate a specific one here.

> Section 6.6:
> 
> In items #5 and #6, what is "an acceptable time span"? Some guidance here 
> would
> be helpful. I believe this is discussed earlier in the draft. Perhaps a
> reference back may provide some clarity?

this extension builds on RFC7401 which does give any explicit time 
values either:

https://tools.ietf.org/html/rfc7401#section-6.8

So I am a bit hesitant to add explicit timeouts here.

> Section 6.9:
> 
> In #1, under what circumstances would the NOTIFY packet not be dropped
> silently? Why is this not a MUST? Some explanation would be useful here. In
> general, many of the SHOULDs in the section 6 subsections, could use further
> justification.

good point, I changed the explicitly mentioned SHOULD to MUST.

Some of SHOULDs in section 6 are inherited from RFC7401. I would like to 
go through all of the SHOULDs in section 6 but it will delay the already 
delayed process for this draft. If we change some of the SHOULDs to 
MUSTs, I believe we need also WG concensus. So, as a quick resolution I 
just added the following note to section 6 intro:

It should be noted that many of the packet processing rules are denoted 
here with "SHOULD" but may be updated to "MUST" when further 
implementation experience provides better guidance.

which I believe reflects the current reality.

> Section 8:
> 
> What is "a reasonable delta time"? Some guidance here would be useful.

good catch. The situation is actually related to sending of I1 packets, 
so I would actually change the time delta to a packet counter similarly 
as in RFC7401:

As an adversary could also send such an ICMP
packet in a man-in-the-middle attack with the aim to prevent the HIP
DEX handshake from completing, the Initiator SHOULD NOT react to an
ICMP message before retransmission counter reaches I1_RETRIES_MAX in
its state machine (see Table 3 in [RFC7401]).

> Section 9 (Security Considerations):
> 
> "The puzzle mechanism using CMAC may need further study regarding the level of
> difficulty." Study of what? Is the concern here that the impact on constrained
> devices at a higher level of difficulty is not well understood? Or is this
> concern around identifying best practices around raising the difficulty under
> specific conditions? A sentence or 

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

[Miika Komu]

Hi,

On 1/20/19 07:59, Tom Henderson wrote:
> On 1/8/19 3:44 PM, Eric Rescorla wrote:
>>
>>
>> On Tue, Jan 8, 2019 at 9:50 AM Tom Henderson > > wrote:
>>
>>     On 1/8/19 5:57 AM, Eric Rescorla wrote:
>>
>>  >     The second preimage attack resistance is 96 bits, plus
>>     whatever work
>>  >     is needed to generate the keys.
>>  >
>>  > I agree that this is in RFC 7343, but it doesn't seem to be stated
>>  > anywhere in this document, and  given that this text talks about
>>     both 64
>>  > bit and >= 100 bit hash functions, I'm not sure how to get it
>>     from this
>>  > text, which is in context quite confusing/
>>
>>     I agree that the text could be clarified; I will try to suggest
>>     something more.
>>
>>  >
>>  >     There isn't any mechanism defined to extend this, such as 
>> the CGA
>>  >     Hash Extension, but it seems to me that HIP could be extended
>>     in a
>>  >     similar way.  My recollection is that the WG had thought 96
>>     bits to
>>  >     be strong enough preimage resistance.
>>  >
>>  > Generally, we are targeting the 128-bit security level for new
>>     deployments
>>  >
>>
>>     Can you provide a reference for the 128-bit recommendation?
>>
>>
>> I don't believe there is a policy, but for instance, see:
>> https://tools.ietf.org/html/rfc7525#section-4.1
>>
>>     Also, how are legacy uses like SEND/CGA handling this new target (or
>>     are
>>     they just considered legacy at this point)?
>>
>>
>> As far as I understand it, they are legacy.
>>
>> -Ekr
>>
> 
> Eric and all,
> 
> In response to this thread, I propose below an additional paragraph to 
> the draft.
> 
> In section 3.1, it discusses requirements on the new namespace in
> general and mentions the desire to avoid collisions, but just lists a
> generic requirement to provide 'authentication services' because the
> cryptographic details are provided later.  As a result, I decided
> against describing second pre-image resistance here.
> 
> In section 4.3, the following paragraph currently concludes the section:
> 
>     In the HIP packets, the HITs identify the sender and recipient of a
>     packet.  Consequently, a HIT should be unique in the whole IP
>     universe as long as it is being used.  In the extremely rare case of
>     a single HIT mapping to more than one Host Identity, the Host
>     Identifiers (public keys) will make the final difference.  If there
>     is more than one public key for a given node, the HIT acts as a hint
>     for the correct public key to use.
> 
> I suggest to add a paragraph as follows:
> 
>     Although it may be rare for an accidental collision to cause a single
>     HIT mapping to more than one Host Identity, it may be the case that
>     an attacker succeeds to find, by brute force or algorithmic weakness,
>     a second Host Identity hashing to the same HIT.  This type of attack
>     is known as a preimage attack, and the resistance to finding a second
>     Host Identifier (public key) that hashes to the same HIT is called
>     second preimage resistance.  Second preimage resistance in HIP is
>     based on the hash algorithm strength and the length of the hash
>     output used.  Through HIPv2 [RFC 7401], this resistance is 96 bits
>     (less than the 128 bit width of an IPv6 address field due to the
>     presence of the ORCHID prefix [RFC7343]).  96 bits of resistance
>     was considered acceptable strength during the design of HIP, but may
>     eventually be considered insufficient for the threat model of an
>     envisioned deployment.  One possible mitigation would be to augment
>     the use of HITs in the deployment with the HIs themselves (and
>     mechanisms to securely bind the HIs to the HITs), so that the HI
>     becomes the final authority.  It also may be possible to increase
>     the difficulty of brute force attack by making the generation of the
>     HI more computationally difficult, such as the hash extension
>     approach of SEND CGAs [RFC 3972], although the HIP specifications
>     through HIPv2 do not provide such a mechanism.  Finally, deployments
>     that do not use ORCHIDs (such as certain types of overlay networks)
>     might also use the full 128-bit width of an IPv6 address field for
>     the HIT.

thanks! Eric, does this address your concerns?

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

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

[Miika Komu]

Hi Eric,

(some other questions still remain to be discussed besides the second 
preimage collision issue)

On 11/21/18 21:37, Eric Rescorla wrote:
> 
> 
> On Tue, Nov 20, 2018 at 12:07 PM Miika Komu  <mailto:mk...@kapsi.fi>> wrote:
> 
> Hi Eric,
> 
> On 5/7/18 00:41, Eric Rescorla wrote:
>  > Eric Rescorla 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:
>  >
> --
>  >
>  > Rich version of this review at:
>  > https://mozphab-ietf.devsvcdev.mozaws.net/D3709
>  >
>  >
>  > Maybe I'm missing something important, but I don't see in this
>  > document how you go from a HI (or HIT) to the corresponding IP
>  > locator. That seems pretty critical to making this work. Can you
> point
>  > me in the right direction?
> 
> (I interpret "right" direction here as how to implement this in
> practice; please let me know if you were asking for something else)
> 
> Existing applications can utilize LSIs or HITs, for instance, via
> /etc/hosts in Linux or if the developer/user uses them directly.
> Mappings can be configured manually. A better way is to use ,e.g., DNS
> to store the FQDN, HIs, IP address mappings:
> 
> https://tools.ietf.org/html/rfc8005
> 
> An application can receive LSIs or HITs from DNS queries when a HI
> record exists for a host. This can be implemented  in the local
> resolver
> library (e.g. glibc in Linux) supports it and sends the HI-to-IP
> address
> mapping to the local HIP daemon. As an alternative implementation
> technique, dynamic relinking of applications (i.e., LD_PRELOAD in
> Linux):
> 
> https://tools.ietf.org/html/rfc6538#section-4.1
> 
> As yet another alternative, RFC5338 (section 3.2) suggests interposing
> HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in
> Linux) that translate HIs into LSIs and HITs to the application and
> cache the IP address mapping to the HIP daemon:
> 
> https://tools.ietf.org/html/rfc5338#section-3.2
> 
> That's all for existing applications. New HIP native applications could
> use DNS library extensions for getaddrinfo() that would be implemented
> e.g. in glibc in Linux:
> 
> https://tools.ietf.org/html/rfc6317
> 
> All of the mentioned references are mentioned in the draft. Should I
> add
> something more compressed along these lines of text or is this too
> detailed?
> 
> 
> Maybe I'm missing something, but it seems like this is not an 
> interoperable state of affairs.

the WG has been experimenting with different ways implementing things. 
Some things are implementation specific (and hence outside of the focus 
of IETF), but, in general, I would argue the most common approach to "go 
from HI or HIT to the corresponding locator" in a typical Linux system 
in the case of a non-hip-aware application works as follows:

1. client app makes are getaddrinfo() call to look up foo.bar from DNS
2. local dns proxy (e.g. standard dnsmasq in Linux) catches the call
3. dns proxy looks up A,  and HI records for foo.bar
3.a. no HI found: dns proxy operates as normally and returns only A/ 
records to the getaddrinfo() call (via glibc) as it would normally
3.b. HI found:
- dnsmasq sends the HI, HIT and IP address to the local HIP daemon
- dnsmasq returns the HIT to the application

The "generic" approach listed here has been tested and implemented (in 
addition some other implementation alternatives mentioned in the HIP 
experiment report). And three different HIP implementations have been 
tested to interoperate with each other.

If this still does not address you concern, please be more specific?

>  > IMPORTANT
>  > S 11.3.1.
>  >>       av

Re: [Hipsec] Opsdir last call review of draft-ietf-hip-rfc4423-bis-19

[Miika Komu]

Hi Will,

On 5/10/18 12:16, Will LIU wrote:
> Reviewer: Will LIU
> Review result: Ready
> 
> Hi all,
> 
> (Sorry , it seems to me that the notification was blocked by the filter. I
> guess it's a little bit late.)

no it's not! It's me who is running late.

> I have reviewed draft-ietf-hip-rfc4423-bis-19 as part of the Operational
> directorate's ongoing effort to review all IETF documents being processed by
> the IESG.  These comments were written with the intent of improving the
> operational aspects of the IETF drafts. Comments that are not addressed in 
> last
> call may be included in AD reviews during the IESG review.  Document editors
> and WG chairs should treat these comments just like any other last call
> comments.
> 
> “This memo describes a new namespace, the Host Identity namespace, and
> a new protocol layer, the Host Identity Protocol, between the
> internetworking and transport layers.  Herein are presented the
> basics of the current namespaces, their strengths and weaknesses, and
> how a new namespace will add completeness to them.  The roles of this
> new namespace in the protocols are defined.
> 
> This document obsoletes RFC 4423 and addresses the concerns raised by
> the IESG, particularly that of crypto agility.  It incorporates
> lessons learned from the implementations of RFC 5201 and goes further
> to explain how HIP works as a secure signaling channel.”
> 
> My overall view of the document is 'Ready' for publication.

thanks!

> Some small ones:
> 
> 1. Especially, I am glad to see the security consideration part well 
> explained.
> I guess it's still worth writing something about the security tradeoff
> influence for the different modes mentioned in previous sections. In fact,
> there are some words in previous sections, maybe a summary can be put here.

I added one line quick summary to the abstract:

[...] The section on security considerations describe also measures 
against flooding attacks, usage of identities in access control lists, 
weaker types of identifiers and trust on first use. [...]

Does this address your concern?

> 2. It's good to have a single subsection about " Answers to NSRG questions".
> However, maybe it's better to put it in appendix?

it's already in appendix (due to other review comments).

Thanks for the feedback!

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

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

[Miika Komu]

Hi Ben,

On 5/10/18 05:53, Ben Campbell wrote:
> 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.)

apologies for this!

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

(Adam already asked to fix a number of compound adjectives)

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

I changed the first sentence to:

This memo describes the Host Identity (HI) namespace, that provides a
cryptographic namespace to applications, and the associated protocol
layer, the Host Identity Protocol, located between the
internetworking and transport layers, that supports end-host
mobility, multihoming and NAT traversal.

Is this ok for you?

> §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).

fixed, thanks!

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

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

[Miika Komu]

Hi Adam,

On 5/10/18 02:34, Adam Roach wrote:
> 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.

thanks for comments!

> 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").

Agreed. I replaced "new" (namespace/layer) to "HI/additional" (depending 
on the context) throughout the document.

> 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...").

thanks

> ---
> §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.

done

> ---
> 
> §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"

fixed, thanks

> ---
> 
> §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"

fixed

> ---
> 
> §6.5:
> 
>>   The control plane between two hosts is terminated using a secure two
>>   message exchange as specified in base exchange specification
> 
> "two-message"

fixed

> ---
> 
> §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".

fixed

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

changed this to:

  such as Teredo [RFC4380]
(as described in further detail in [varjonen-split]).


> ---
> 
> §8:
> 
>>   can map to a single IP address on a 

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

[Miika Komu]

Hi Benjamin,

On 5/9/18 23:58, Benjamin Kaduk wrote:
> 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.

we'll address the comments in a response to Eric's original email.

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

Adding -s in the end of the verbs (enhances / aids / reduces) probably 
fixes the issue you mentioned?

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

The text has changed a bit during the reviews, but I changed the wording 
to uppercase now:

In this document, some non-cryptographic forms of HI and HIP are 
referenced, but cryptographic forms SHOULD be preferred because they are 
more secure than their non-cryptographic counterparts.

(Btw, the type of draft is "informal" so I am not sure how much mandate 
this has, but changed nevertheless)

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

should I add something, I think privacy is mentioned already on the 
first sentence?

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

I would suggest the following to simplify the text a bit:

When a mobile node moves while communication is already on-going,
address changes are rather straightforward.  The mobile node sends a
HIP UPDATE packet to inform the peer of the new address(es), and the
peer then verifies that the mobile node is reachable through these
addresses.  This way, the peer can avoid flooding attacks as further
discussed in Section 11.2.

Does that work for you?

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

added some text in parenthesis:

one to publish in DNS or similar directory service and an unpublished 
one for anonymous usage (that 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 

Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Miika Komu]

Hi Mirja,

On 5/7/18 16:42, Mirja Kühlewind wrote:
> Mirja Kühlewind 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:
> --
> 
> A few minor high-level comments/questions:
> 
> 1) To me it feels that sec 11 doesn't really belong in this bis doc. Maybe 
> that
> is rather an own report or can just go in the appendix?

ok, moving this to appendix.

> 2) Should this document maybe discuss connection migration as used by QUIC as
> an alternative (based on short term connection identifiers instead of course)?
> Background: to provide identities between two endpoints, I'd say that TLS is
> sufficient or even the more appropriate solution. However, this document does
> not talk very much about cases where the identify of other IP hosts (not
> endpoints) is important. Oft course it covers the mobility use case but that
> also seems less relevant with migration support in QUIC.

There are many protocols that HIP could be compared against but the WG 
did not pursue to do it in the context of this document. TLS and QUIC 
are application-layer protocols whereas HIP operates between transport 
and network layers, so I am not sure how fair comparison we could make. 
Also, at this stage of the draft I think it would better to reference 
some existing peer reviewed work but I doubt anyone has done a 
comparison of HIP and QUIC.

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

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

[Miika Komu]

Hi Eric,

On 5/7/18 00:41, Eric Rescorla wrote:

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3709


Maybe I'm missing something important, but I don't see in this
document how you go from a HI (or HIT) to the corresponding IP
locator. That seems pretty critical to making this work. Can you point
me in the right direction?


(I interpret "right" direction here as how to implement this in 
practice; please let me know if you were asking for something else)


Existing applications can utilize LSIs or HITs, for instance, via 
/etc/hosts in Linux or if the developer/user uses them directly. 
Mappings can be configured manually. A better way is to use ,e.g., DNS 
to store the FQDN, HIs, IP address mappings:


https://tools.ietf.org/html/rfc8005

An application can receive LSIs or HITs from DNS queries when a HI 
record exists for a host. This can be implemented  in the local resolver 
library (e.g. glibc in Linux) supports it and sends the HI-to-IP address 
mapping to the local HIP daemon. As an alternative implementation 
technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux):


https://tools.ietf.org/html/rfc6538#section-4.1

As yet another alternative, RFC5338 (section 3.2) suggests interposing 
HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in 
Linux) that translate HIs into LSIs and HITs to the application and 
cache the IP address mapping to the HIP daemon:


https://tools.ietf.org/html/rfc5338#section-3.2

That's all for existing applications. New HIP native applications could 
use DNS library extensions for getaddrinfo() that would be implemented 
e.g. in glibc in Linux:


https://tools.ietf.org/html/rfc6317

All of the mentioned references are mentioned in the draft. Should I add 
something more compressed along these lines of text or is this too detailed?



IMPORTANT
S 11.3.1.

  avoiding manual configurations.  The three components are further
  described in the HIP experiment report [RFC6538].
   
  Based on the interviews, Levae et al suggest further directions to

  facilitate HIP deployment.  Transitioning the HIP specifications to
  the standards track may help, but other measures could be taken.  As


This confuses me, because we seem to be looking to advance some of the
HIP specs (e.g., hip-dex) at PS


Can you elaborate? And do you mean protocol stack by PS?

(This text is based on the subjective opinions of the interviewed 
people. So I don't think it matters so much)



COMMENTS
S 3.1.

 were obtained.  For 64 bits, this number is roughly 4 billion.  A
 hash size of 64 bits may be too small to avoid collisions in a
 large population; for example, there is a 1% chance of collision
 in a population of 640M.  For 100 bits (or more), we would not
 expect a collision until approximately 2**50 (1 quadrillion)
 hashes were generated.


It's not just a matter of collisions being hard, but also of being
difficult to produce an HI with a given name.


where name would be the hash (i.e. HIT). So I added:

Besides accidental collisions, it is also worth noting that intentional 
collisions are difficult to accomplish because generating a valid, 
colliding hash along with its private-public key is computationally 
challenging.


Did I capture your thinking correctly?


S 4.

  'well known', some unpublished or 'anonymous'.  A system may self-
  assert its own identity, or may use a third-party authenticator like
  DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
  to another namespace.  It is expected that the Host Identifiers will
  initially be authenticated with DNSSEC and that all implementations
  will support DNSSEC as a minimal baseline.


This wasn't a very good assumption when 4423 was published, and it
seems even worse now, given the low rate of deployment of DNSSEC and
the fact that we know many middleboxes break DNSSEC.


Then I guess it would be fine to remove the last sentence?


S 4.3.

  packet.  Consequently, a HIT should be unique in the whole IP
  universe as long as it is being used.  In the extremely rare case of
  a single HIT mapping to more than one Host Identity, the Host
  Identifiers 

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] Genart telechat review of draft-ietf-hip-native-nat-traversal-28

[Miika Komu]

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!

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

Re: [Hipsec] [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27

[Miika Komu]

Hi Roni,

sorry, I read your email a bit too late today. I was too trigger happy 
and posted a new version... I thought it would be good to avoid blocking 
IANA with some missing and incorrect details.


On 03/04/2018 09:22 AM, Roni Even (A) wrote:

Hi Miika,
  All your responses are OK with me.

As for posting a new version, I think it will be good to submit one with all 
the changes that came in the IETF LC

Roni

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Miika Komu
Sent: Thursday, March 01, 2018 4:13 PM
To: Roni Even; gen-...@ietf.org
Cc: hipsec@ietf.org; i...@ietf.org; 
draft-ietf-hip-native-nat-traversal@ietf.org
Subject: Re: [Gen-art] Genart last call review of 
draft-ietf-hip-native-nat-traversal-27

Hi Roni,

thanks for the detailed review! My comments are below.

On 02/26/2018 03:21 PM, Roni Even wrote:

Reviewer: Roni Even
Review result: Almost Ready

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 treat these comments just like
any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. in section 4.2 "Gathering of candidates MAY also be performed by
other means than described in this section.  For example, the candidates could 
be
 gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
 available, or if the host has just a single interface and no STUN orData
 Relay Server are available." I did not see this a different ways since
 section 3 says "The hosts use either Control Relay Servers or Data Relay
 Servers (or other infrastructure including STUN or TURN servers) for
 gathering the candidates." so STUN is mentioned also here.


I suggest to remove the remark in parenthesis (or other infrastructure 
including STUN or TURN servers). Does this solve the issue?

[Roni] Yes


2. In section 4.6.2 "The connectivity check messages MUST be paced by
the Ta value negotiated during the base exchange as described in
Section 4.4.  If neither one of the hosts announced a minimum pacing
value, a value of  20 ms SHOULD be used." in section 4.4 the default value is 
50 ms?


Good catch! I double checked this from the ICE spec, which defaults also to 50 
ms. So, I change the value to 50 ms also in section 4.6.2.
[Roni] OK


3. in section 5.4 what about "ICE-STUN-UDP 2" ;  I assume it is not
relevant but this is also the IANA registeration


I think it makes sense to add the missing one as you suggest, but omit it from 
the IANA registration since it is already registered for RFC5770.
[Roni] OK


4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is
not new it is in RFC5770


You're right, I'll change this.
[Roni]OK


5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63"
is the only new one. this also relates to section 7 that says that all
error values in section 5.10 are new while the rest are in RFC5770.
Also there is no mention in section 7 of which registry is used for the error 
values.


Good catch, I'll correct these and add the IANA registry.

[Roni]OK


Nits/editorial comments:
1. Expand SPI and LSI when first appear in the document

2. in section 2 "the base of an candidate" should be "a candidate"

3. In section 3 "so it is the Initiator may also have registered to a
Control and/or Data Relay Server" maybe "so  the Initiator may also
need to register to a Control and/or Data Relay Server"

4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client
registers a new server reflexive candidate for each its peer for the
reasons described" maybe "for each of its..."


Thanks for spotting these, will fix as suggested.


5. In section 4.2 I could not parse the sentence "where Ta is the
value used for Ta is the value used for the"


Should be "where Ta is the value used for the"...


6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:"  change
to "as defined in section 6.7 in [RFC7401]:"


Will fix this too.

Should I post a new version with the suggested changes?


___
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

Re: [Hipsec] Genart last call review of draft-ietf-hip-native-nat-traversal-27

[Miika Komu]

Hi Roni,

thanks for the detailed review! My comments are below.

On 02/26/2018 03:21 PM, Roni Even wrote:

Reviewer: Roni Even
Review result: Almost Ready

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. in section 4.2 "Gathering of candidates MAY also be performed by other means
than described in this section.  For example, the candidates could be
gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
available, or if the host has just a single interface and no STUN orData
Relay Server are available." I did not see this a different ways since
section 3 says "The hosts use either Control Relay Servers or Data Relay
Servers (or other infrastructure including STUN or TURN servers) for
gathering the candidates." so STUN is mentioned also here.


I suggest to remove the remark in parenthesis (or other infrastructure 
including STUN or TURN servers). Does this solve the issue?



2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta
value negotiated during the base exchange as described in Section 4.4.  If
neither one of the hosts announced a minimum pacing value, a value of  20 ms
SHOULD be used." in section 4.4 the default value is 50 ms?


Good catch! I double checked this from the ICE spec, which defaults also 
to 50 ms. So, I change the value to 50 ms also in section 4.6.2.



3. in section 5.4 what about "ICE-STUN-UDP 2" ;  I assume it is not
relevant but this is also the IANA registeration


I think it makes sense to add the missing one as you suggest, but omit 
it from the IANA registration since it is already registered for RFC5770.



4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it
is in RFC5770


You're right, I'll change this.


5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63" is the
only new one. this also relates to section 7 that says that all error values in
section 5.10 are new while the rest are in RFC5770. Also there is no mention in
section 7 of which registry is used for the error values.


Good catch, I'll correct these and add the IANA registry.


Nits/editorial comments:
1. Expand SPI and LSI when first appear in the document

2. in section 2 "the base of an candidate" should be "a candidate"

3. In section 3 "so it is the Initiator may also have registered to a Control
and/or Data Relay Server" maybe "so  the Initiator may also need to register to
a Control and/or Data Relay Server"

4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client
registers a new server reflexive candidate for each its peer for the reasons
described" maybe "for each of its..."


Thanks for spotting these, will fix as suggested.


5. In section 4.2 I could not parse the sentence "where Ta is the value used
for Ta is the value used for the"


Should be "where Ta is the value used for the"...


6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:"  change to "as
defined in section 6.7 in [RFC7401]:"


Will fix this too.

Should I post a new version with the suggested changes?

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

Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19

[Miika Komu]

Hi Sean,

On 02/27/2018 05:06 PM, Sean Turner wrote:

Reviewer: Sean Turner
Review result: Has Nits

This is a bis draft of the HIP (Host Identity Protocol) Architecture and
because of that I focused on what’s changed (i.e., I reviewed the diffs from
https://www.ietf.org/rfcdiff?url1=rfc4423=draft-ietf-hip-rfc4423-bis-18).
It’s still HIP but with a slightly expanded scope; it’s still Informational.

1. s4: The one place where I’ll step out from not looking at the old is a
similar-ish recommendation that was in the RF4423:

In this document, the non-cryptographic forms of HI and HIP are
presented to complete the theory of HI, but they should not be
implemented as they could produce worse denial-of-service attacks
than the Internet has without Host Identity.

Should the should not be a SHOULD NOT?


I can change this for sure but the whole document is written without the 
capitalized terms due to its informal nature... actually, this sentence 
is a bit moot since non-cryptographic forms of HI are only referenced in 
the text. I would suggest rephrasing this as follows:


"In this document, some non-cryptographic forms of HI and HIP are
referenced, but cryptographic forms should be preferred because they are 
more secure than their non-cryptographic counterparts."


Would that work for you?


2. (none security) s4.4: Is the paragraph about IPv4 vs IPv6 vs LSI really
necessary?  I.e., is this yet another thing that folks are going to use to not
transition to IPv6?


I think the draft should discuss IPv4 compatibility because it is part 
of architecture design.


Btw, do you mean this paragraph or something else?

   The interoperability mechanism
   should not be used to avoid transition to IPv6; the authors firmly
   believe in IPv6 adoption and encourage developers to port existing
   IPv4-only applications to use IPv6.  However, some proprietary,
   closed-source, IPv4-only applications may never see the daylight of
   IPv6, and the LSI mechanism is suitable for extending the lifetime of
   such applications even in IPv6-only networks.

IMHO, the LSIs should be supported mainly for the sake of proprietary, 
legacy applications which should be supported for backwards 
compatibility. The next paragraph also mentions a limitation of the LSIs:


The main disadvantage of an LSI is its local scope.  Applications may
   violate layering principles and pass LSIs to each other in
   application-layer protocols.

Let me know if you would like change or emphasize something?


3. s11.2: Isn’t an additional drawback the need to have a HIP-aware firewall?


Good point. It's both a benefit and drawback from the viewpoint of 
firewalls. s11.1 mentions:


  [...] First, the use of
  HITs can potentially halve the size of access control lists
  because separate rules for IPv4 are not needed [komu-diss].
  Second, HIT-based configuration rules in HIP-aware middleboxes
  remain static and independent of topology changes, thus
  simplifying administrative efforts particularly for mobile
  environments.

As a drawback, I could add something like this to s11.2:

In the current Internet, firewalls are commonly used to control access 
to various services and devices. Since HIP introduces a new namespace, 
it is expected that also the HIP namespace would be filtered for 
unwanted connectivity. While this can be achieved with existing tools 
directly in the end-hosts, filtering at the middleboxes requires 
modifications to existing firewall software or new middleboxes [RFC6538].


How does this sound?

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

Re: [Hipsec] Genart last call review of draft-ietf-hip-rfc4423-bis-18

[Miika Komu]

Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture 
document are below (in "diff" format).


On 02/18/2018 07:33 AM, Joel Halpern wrote:

Reviewer: Joel Halpern
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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-hip-rfc4423-bis-18
Reviewer: Joel Halpern
Review Date: 2018-02-17
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as an Informational RFCs.
  The following comments may be useful for the authors to consider.

Major issues: N/A

Minor issues:
 In the table in section 2.2 (Terms specific to this and other HIP
 documents) the Host Identity Hash is defined as "The cryptographic hash
 used in creating the Host Identity Tag from the Host Identity."  I am
 pretty sure the last word should be Identifier, not Identity,, which
 matches the meanings and the usage in the following term.


agreed. Suggested change:

   Host Identity Hash  The cryptographic hash used
-  in creating the Host Identity Tag from the Host Identity.
+  in creating the Host Identity Tag from the Host Identifier.
 (I will move the definition of Host Identifier earlier so that the 
terms appear in chronological order)



 In section 4.1 second paragraph, it seems odd to refer to the
 public-private key pair as the structure of the abstract Host Identity.
 Given that the earlier text refers to the Public key as the Host
 Identifier, I am not sure how you want to refer to the public/private key
 pair.  But I do not think it "is" the structure of the Host Identity.


Agree. Suggested rephrasing:

-The only completely defined structure of the Host Identity
-is that of a public/private key pair.  In this case, the Host
-Identity is referred to by its public component, the public
+An identity is based on public-private key cryptography in HIP.
+The Host Identity is referred to by its public component, the 
public

 key.


 In the section 4.4 discussion of locally scoped identifier (LSI), it
 appears that applications need to be modified to use this.  Reading between
 the lines of the stack architecture, the actual advantage of using HIP with
 LSIs is that the application changes can be restricted to whatever
 indication is to be used that the stack is to use HIP, rather than changing
 the places that use sockaddrs, etc.  But this is not clearly stated here.


yes, you are correct. I would suggest the following changes to make this 
more clear:


 A Host Identity Tag is a 128-bit representation for a Host
-Identity.  It is created from an HIH,
-an IPv6 prefix [RFC7343] and a hash identifier.
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv6 addresses (e.g. in sockaddr_in6 structure, 
sin6_addr member) without modifying applications.

+It is created from an HIH, an IPv6 prefix [RFC7343]
+and a hash identifier.

...and the following:

 An LSI is a 32-bit localized representation for a Host
-Identity. The purpose of an LSI is to facilitate using Host
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv4 addresses (e.g. in sockaddr_in structure, 
sin_addr member) without modifying applications.

+The purpose of an LSI is to facilitate using Host
 Identities in existing APIs for IPv4-based
-applications. Besides facilitating HIP-based connectivity for
+applications.
+LSIs are never transmitted on the wire; when an application
+sends data using a pair of LSIs, the HIP layer (or sockets
+handler) translates the LSIs to the corresponding HITs, and
+vice versa for receiving of data.
+Besides facilitating HIP-based connectivity for
 legacy IPv4 applications, the LSIs are beneficial in two other
 scenarios [RFC6538].

@@ -712,6 +721,14 @@
 to facilitate backward compatibility with existing networking
 APIs and stacks.


 In section 5.1 paragraph 3, the text talks about a connecting client not
 specifying a responder identifier (HIP Opportunistic mode) in order to
 enable load balancing.  I think the text would be helped by an example of
 how an initiator might know to do this, rather than just not using HIP.
 Also, it would be good if the text was explicit as to whether or not there
 was a way to support load balancing / multi servers without either using a
 shared identity or sacrificing security by using Opportunistic HIP.


agreed, the 

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-27.txt

[Miika Komu]

FYI,

added the missing RELAY_UDP_HIP in section 5.9. Registration Types and 
fixed a couple a small typos in the text.


Gonzalo: I have no further changes to the document.

On 12/20/2017 11:31 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-27.txt
Pages   : 60
Date: 2017-12-20

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-27
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-27


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-26.txt

[Miika Komu]

Hi,

in this new version, I have fixed id nits according to request from 
Gonzalo. The nits are here:


https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-hip-native-nat-traversal-25.txt

On 12/20/2017 09:02 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-26.txt
Pages   : 60
Date: 2017-12-20

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-26
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-26

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-26


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-23

[Miika Komu]

Hi,

thanks Tom! I applied your fixes to the version 25 of the document.

On 12/08/2017 08:04 AM, Tom Henderson wrote:

Gonzalo,
I've read the draft again, and sent Miika some editorial comments.  I 
believe it is ready to publish.


- Tom

On Wed, 22 Nov 2017, Gonzalo Camarillo wrote:


Folks,

we already WGLCed version 15 of this draft back in February. Miika has
addressed a few comments since then. I would like to start a second WGLC
on the the draft to make sure it is ready for publication request. This
WGLC will end on December 7th:

https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

Thanks,

Gonzalo

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



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


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

Re: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-18.txt

[Miika Komu]

FYI,

the only change was that I updated the HIP certificate draft reference 
from "bis" to RFC8002.


On 11/23/2017 01:35 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Host Identity Protocol Architecture
 Authors : Robert Moskowitz
   Miika Komu
Filename: draft-ietf-hip-rfc4423-bis-18.txt
Pages   : 42
Date: 2017-11-23

Abstract:
This memo describes a new namespace, the Host Identity namespace, and
a new protocol layer, the Host Identity Protocol, between the
internetworking and transport layers.  Herein are presented the
basics of the current namespaces, their strengths and weaknesses, and
how a new namespace will add completeness to them.  The roles of this
new namespace in the protocols are defined.

This document obsoletes RFC 4423 and addresses the concerns raised by
the IESG, particularly that of crypto agility.  It incorporates
lessons learned from the implementations of RFC 5201 and goes further
to explain how HIP works as a secure signaling channel.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-18
https://datatracker.ietf.org/doc/html/draft-ietf-hip-rfc4423-bis-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-23.txt

[Miika Komu]

FYI,

the major changes in this version are:

4.12.3. Handling Conflicting SPI Values
* a new way to handle conflicting SPIs by utilizing multiple relayed 
candidates

* this changed affected also sections 4.1, 4.2, 4.12.1, 5.13.

4.9.  Mobility Handover Procedure:
* the exchange of locators must be three way in order to avoid replay 
attacks

* clarified double jump

Minor changes:

4.7.1.  Minimal NAT Traversal Support:
* clarified how mobility is supposed to work in this case

4.10. NAT Keepalives:
* the Data Relay Client and Data Relay Server MUST employ only HIP 
NOTIFY packets in order to keep the server reflexive candidates alive


5.10. Notify Packet Types:
* A new error value: SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED

5.13.  PEER_PERMISSION Parameter
* Additional port and address added because multiple server reflexive 
candidates can be leased


6.2. Opportunistic Mode
* Clarified that anycast and multicast are out of scope

7.  IANA Considerations
* Error values are listed also here

Appendix D.  Multihoming Considerations:
* new section on future compatibility with possible multihoming extensions

* Some minor clarifications here and there

On 11/12/2017 11:00 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-23.txt
Pages   : 60
Date: 2017-11-12

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-23
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-22.txt

[Miika Komu]

Hi,

the HIP multihoming reference was incorrect in version 21. Fixed it 
before I forget about it... sorry for the spam :)


On 10/23/2017 07:18 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-22.txt
Pages   : 56
Date: 2017-10-23

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-22
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-22


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-21.txt

[Miika Komu]

Hi,

this is a keepalive with some minor changes based on offline review 
comments from Ari:


* NAT penetration -> NAT traversal
* Added some extra internal references to Section 6.5 in the document
* CANDIDATE_DISCOVERY is included again; no need to omit it even though 
multihoming is left for further study (added also a proper reference to 
the multihoming draft)


Diff:

https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-21

On 10/23/2017 07:08 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-21.txt
Pages   : 56
Date: 2017-10-23

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-21
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-17.txt

[Miika Komu]

FYI,

this version is just a keepalive.

On 08/07/2017 06:08 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol WG of the IETF.

 Title   : Host Identity Protocol Architecture
 Authors : Robert Moskowitz
   Miika Komu
Filename: draft-ietf-hip-rfc4423-bis-17.txt
Pages   : 42
Date: 2017-08-07

Abstract:
This memo describes a new namespace, the Host Identity namespace, and
a new protocol layer, the Host Identity Protocol, between the
internetworking and transport layers.  Herein are presented the
basics of the current namespaces, their strengths and weaknesses, and
how a new namespace will add completeness to them.  The roles of this
new namespace in the protocols are defined.

This document obsoletes RFC 4423 and addresses the concerns raised by
the IESG, particularly that of crypto agility.  It incorporates
lessons learned from the implementations of RFC 5201 and goes further
to explain how HIP works as a secure signaling channel.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-17
https://datatracker.ietf.org/doc/html/draft-ietf-hip-rfc4423-bis-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc4423-bis-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt

[Miika Komu]

Hi,

so in addition to Christer's comments...

https://mailarchive.ietf.org/arch/msg/hipsec/iPSdqgR6e2lK7LZqUfCBnkLxZn8
https://mailarchive.ietf.org/arch/msg/hipsec/LLsY1BqJdmc5foSk9QhYzUWRDvE

...I took the liberty of improving the draft editorially while reviewing 
it (+ one paragraph was removed):


1. Introduction
* Added a note that legacy ICE-HIP refers to HIPv1 and this is one 
refers HIPv2 explicitly


2. Terminology:
* HIP connectivity checks, Controlling host, Controlled host (minor 
editorial improvements)


3. Overview:
* Data Relay Server is not mandatory
* What the Data Relay Server actually does (translates source address)
* Strictly speaking only Responder requires the Data Relay Server

4.2. Transport Address Candidate Gathering at the Relay Client

* CANDIDATE_DISCOVERY parameter requires multihoming capabilities which 
is out of scope, so I removed it


4.5.  Base Exchange via Control Relay Server
* "It is RECOMMENDED to use the same Control Relay Server throughout the 
lifetime of the host association that was used for forwarding the base 
exchange if the	Responder includes it in the locator parameter of the R2 
message."


4.6.1.  Connectivity Check Procedure

* Added this section: "It should be noted that in the case both 
Initiator and Responder both advertising their own relayed address 
candidates [..]" to clarify what happens in this case of both ends 
advertise their own TURN servers and that asymmetric paths are possible


4.12.3.  Handling Conflicting SPI Values

* Editorial fixes to make the two cases more understandable


If you want to see the diff in detail, please check from here:

https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20


On 04/25/2017 02:47 PM, Miika Komu wrote:

Hi,

this version addresses Christer's earliers comments and fixes some other
issues I discovered while reviewing the draft. I'll send a summary of
the comments a bit later.

On 04/25/2017 02:05 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host
Identity Protocol
Authors : Ari Keranen
  Jan Melén
      Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-20.txt
Pages   : 56
Date: 2017-04-25

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-20


A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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


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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt

[Miika Komu]

Hi,

I have commented out the section numbers.

On 03/28/2017 07:16 PM, Christer Holmberg wrote:

Hi,

Another comment:

The draft references specific sections in draft-ice-5245bis.

Note that there is some ongoing re-structuring of 5245bis, which means the 
section numbers may change.

Regards,

Christer

-Original Message-
From: Hipsec [mailto:hipsec-boun...@ietf.org] On Behalf Of Miika Komu
Sent: 27 March 2017 10:41
To: hipsec@ietf.org
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt

Hi,

the preliminary version is now published as it is (except I had to change 
publication the date). The suggestions from Christer are not yet here and will 
require some time to be fixed.

On 03/27/2017 10:37 AM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
Authors : Ari Keranen
  Jan Melén
  Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-19.txt
Pages   : 53
Date: 2017-03-27

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traver
sal-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-
19


Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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



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

Re: [Hipsec] Comments on draft-hip-native-nat-traversal-19

[Miika Komu]

Hi Christer,

On 03/26/2017 02:34 AM, Christer Holmberg wrote:

Hi,

As co-author for the ICEbis draft, I was asked to review
draft-hip-native-nat-traversal-19.

I have not had time to review the whole document. However, many of my
comments are generic, and apply to the whole document.


thanks for the feedback! Your (editorial) comments should be addressed 
in this version:


https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20

The diff is here:

https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20


I have no knowledge of HIP, so I will not comment on HIP issues like
 messages, parameters etc used.


If one implements this, some digging into the HIP documents is needed. 
From a design perspective, the document should be readable as it is (I 
hope).



General: ===

QG0: Throughout the document, you use RFC 2119 terminology (SHOULD,
MUST etc with capital letters) when you refer to procedures and rules
defined elsewhere. I think that is wrong, and it also makes it very
difficult what exactly is defined in this document, and what is
defined in some other specification.


I am keeping the SHOULD/MUST/etc for HIP documents (since this is an 
extension of HIP) but ICE references are now with small letters (there 
actually weren't too many).



QG1: You say that the mechanism in the draft is based on ICE. I think
it would be good to give a name to the mechanism. "HIP-ICE", or
something similar.


Done:

   ICE:
  Interactive Connectivity Establishment (ICE) protocol as specified
  in [I-D.ietf-ice-rfc5245bis]

   Legacy ICE-HIP:
  Refers to the "Basic Host Identity Protocol (HIP) Extensions for
  Traversal of Network Address Translators" as specified in
  [RFC5770].  The protocol specified in this document offers an
  alternative to Legacy ICE-HIP.

   Native ICE-HIP:
  The protocol specified in this document (Native NAT Traversal Mode
  for HIP).


QG2: I would also like to have a dedicated section which on a
high-level describes the differences/restrictions between legacy ICE
and HIP-ICE. It helps very much when later reading the details in
section 4. That section should at least list the different types of
functions (HIP relays etc) are used for gathering candidates, what
protocol (HIP messages) is used instead of STUN, what types of
candidates are used and how they are retrieved.


The ICE comparison has been already in the previous version in Appendix 
B ("Differences with respect to ICE") and now the intro also references 
this section ("Appendix B explains the differences to ICE."). I think 
it's not good to start the document with a diff to ICE. We have to 
assume that the reader is familiar with HIP since this is an extension 
to it.



It would also be good to give a short overview of the HIP messages
used for the connectivity checks. It is very useful when later
reading the details.


The intro now includes a really short intro to HIP, but I don't think we 
should introduce the messaging formats here again. This is an extension 
to HIP, so some familiarity with HIP is required.


(Btw, the ICE specification does not describe STUN/TURN messaging 
formats either, so the situation is the same for that document)



QG3: You should use consistent terminology when you talk about
endpoints and relays. Sometimes the text says "host", sometimes "HIP
 relay server client", sometimes "relay client", sometimes
"end-host". Sometimes you say "HIP relay", sometimes "HIP server
relay", etc. Sometimes you say "non-relay host", which suggests that
the relay is also a host.


the document has over 300 occurrences of host, could you be a bit more 
specific where this is a problem? "End-host" means "non-relay host", and 
yes, a relay is a host too.


I agree the client/server relay terminology was a bit sloppily used. In 
general, I think the terms were a bit asymmetrical:


* HIP vs. data relay, why not just "control" and "data"
* HIP relay vs HIP relay client (why not HIP relay *server*)

So I came up with a better relay terminology that is now applied 
consistently throughout the document:


   Control Relay Client:
  A requester host that registers to a Control Relay Server
  requesting it to forward control-plane traffic (i.e.  HIP control
  messages).  In the Legacy ICE-HIP specification, this is denoted
  as "HIP Relay Client".

   Data Relay Server:
  A registrar host that forwards HIP related data plane packets,
  such as Encapsulating Security Payload (ESP) [RFC7402], between

  two hosts.  This host implements similar functionality as TURN
  servers.

   Data Relay Client:
  A requester host that registers to a Data Relay Server requesting
  it to forward data-plane traffic (e.g.  ESP traffic).


Section 3: 

Q30: The text says:

"The hosts may use HIP relay servers (or even STUN or TURN servers)
for gathering the candidates."

This is confusing, as you have earlier said that HIP-ICE doesn't 

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt

[Miika Komu]

Hi,

this version addresses Christer's earliers comments and fixes some other 
issues I discovered while reviewing the draft. I'll send a summary of 
the comments a bit later.


On 04/25/2017 02:05 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
Authors : Ari Keranen
  Jan Melén
  Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-20.txt
Pages   : 56
Date: 2017-04-25

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt

[Miika Komu]

Hi Jeff,

thanks, good catch. This change will be in the next version.

On 03/28/2017 06:11 PM, Jeff Ahrenholz wrote:

Hi Miika,
The new paragraph on keepalives (Section 5.3) looks good.

For the NOTIFY code, NAT_KEEPALIVE value (“TBD by IANA: 16384”) maybe suggest 
16385? ...since we already have “I2_ACKNOWLEDGEMENT 16384” in RFC 5201 and RFC 
7401.

thanks,
-Jeff

On 3/27/17, 12:41 AM, "Hipsec on behalf of Miika Komu" <hipsec-boun...@ietf.org on 
behalf of miika.k...@ericsson.com> wrote:

Hi,

the preliminary version is now published as it is (except I had to
change publication the date). The suggestions from Christer are not yet
here and will require some time to be fixed.

On 03/27/2017 10:37 AM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the Host Identity Protocol of the IETF.
>
> Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
> Authors : Ari Keranen
>   Jan Melén
    >   Miika Komu
>Filename: draft-ietf-hip-native-nat-traversal-19.txt
>Pages   : 53
>Date: 2017-03-27
>
> Abstract:
>This document specifies a new Network Address Translator (NAT)
>traversal mode for the Host Identity Protocol (HIP).  The new mode is
>based on the Interactive Connectivity Establishment (ICE) methodology
>and UDP encapsulation of data and signaling traffic.  The main
>difference from the previously specified modes is the use of HIP
>messages for all NAT traversal procedures.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19
> 
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-19
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-19
>
>
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>

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




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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt

[Miika Komu]

Hi,

the preliminary version is now published as it is (except I had to 
change publication the date). The suggestions from Christer are not yet 
here and will require some time to be fixed.


On 03/27/2017 10:37 AM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
Authors : Ari Keranen
  Jan Melén
  Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-19.txt
Pages   : 53
Date: 2017-03-27

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19
https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-19


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15

[Miika Komu]

Hi,

On 03/15/2017 04:37 PM, Jeff Ahrenholz wrote:

I might suggest to recommend NOTIFY (and define the keepalive) and state
that other messages including ICMPv6 or UPDATE may be substituted.  If
there is a need for bi-directional connectivity checking, recommend to use
UPDATE;  if there are specific known scenarios where an ICMPv6 is
recommended instead, state those scenarios.


Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I
think we shouldn't device a new UPDATE mechanism tied to controlled role
(sorry for thinking aloud :)

Jeff, is this ok for you?


Yes, this sounds good.


I have reflected this discussion now in section 5.3 of the preliminary 
version:


http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

   The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
   as specified in [RFC7401] with Notify message type field set to
   NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification
   data field.  It is worth noting that sending of such a HIP NOTIFY
   message MAY be omitted if the host is actively (or passively) sending
   other traffic to the peer host over the UDP tunnel associate with the
   host association (and IPsec security associations since the same port
   pair is reused) during the Tr period.  For instance, the host MAY
   actively send ICMPv6 requests (or respond with an ICMPv6 response)
   inside the ESP tunnel to test the health of the associated IPsec
   security associations.  Alternatively, the host MAY use UPDATE
   packets as a substitute.  A minimal UPDATE packet would consist of a
   SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
   rekeying procedures as specified in section 6.8 in [RFC7402].  It is
   worth noting that a host actively sending periodic UPDATE packets to
   a busy server may increase the computational load of the server since
   it has to verify HMACs and signatures in UPDATE messages.

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

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15

[Miika Komu]

Hi Tom,

On 03/14/2017 11:19 AM, Miika Komu wrote:

[..]


A couple of fixes for me to edit:

* Appendix B: normative vs non-normative terminology

> [...]

so the appendix was using normative terminology which was a bit strange. 
As a quick fix, I thought about moving this appendix to the body, but 
after reading this extension (that was inherited as a legacy from the 
earlier specification) I decided to remove it. The section basically 
suggested allowing source routing via HIP relay for the sake of 
compatibility with RVS servers. I think this could be exploited in a bad 
way to DoS other hosts. I think it is more secure if the HIP relay only 
forwards inbound packets, not outbound. If you disagree with this 
change, please discuss on the list.


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

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15

[Miika Komu]

Hi,

a preliminary version here:

http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

Not yet on IETF site since I missed the cut-off deadline.

On 02/19/2017 05:18 PM, Tom Henderson wrote:

Hello, I have read the latest (-17) draft and sent some purely editorial
comments to Miika.  I had a few non-editorial questions and comments.

1) In appendix D, it states:

   o  A minimal implementation would conform only to Section 4.7.1 or
  Section 4.7.2, thus merely tunneling HIP control and data traffic
  over UDP.  The drawback here is that it works only in the limited
  cases where the Responder has a public address.

However, in section 5.4, it states:

   Implementations conforming to this specification MUST implement both
   UDP-ENCAPSULATION and ICE-HIP-UDP modes.

The contradictory text should be resolved.  In my opinion,
implementations that want to support only the UDP-ENCAPSULATION mode
(and its restricted set of use cases) should be allowed.  However, I
don't know what might need to be done to avoid a situation where a
product claims RFC compliance but only implements one of the two modes.
It could perhaps be avoided by a statement that states "Implementations
that choose to only support the UDP-ENCAPSULATION mode should clarify
this point when any claims of  compliance are made."


now it says:

"Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes."

I can also add some other wording if it is really necessary (and common 
in RFC specifications). Btw, while ICE lite is not really the same as 
ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the 
specification.



2) Appendix C states:

   o  The considerations on Diffserv Codepoint markings in ICE are not
  applicable to HIP since Diffserv is not used in HIP.

Why wouldn't the same issues arise in HIP as in ICE on this matter?
Should this draft instead copy or reference the RFC 5245 recommendation:

   If the agent is using Diffserv Codepoint markings [RFC2475] in its
   media packets, it SHOULD apply those same markings to its
   connectivity checks.

Also, I don't think that the HIP control plane should be excluded from
using diffserv.


done.


3) In section 4.10 (NAT keepalives), it states:

   Both a registered client and relay server SHOULD
   send a HIP NOTIFY packets to each other every 15 seconds (the so-
   called Tr value in ICE) unless they have exchange some other traffic
   over the used UDP ports.

However, I couldn't find an explanation anywhere (also in RFC 5770)
about how to code this NOTIFY.  Would it make sense to define also a
"NAT_KEEPALIVE" NOTIFY message type for this purpose?

Once these issues are resolved, I think that the draft would be ready to
publish.


done.

P.S. The new version of the draft also includes some nits from Alex Elsayed.

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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-15.txt

[Miika Komu]

Hi Jeff,

thanks for quick feedback, fixed this in version 16.

On 02/01/2017 06:06 PM, Jeff Ahrenholz wrote:

Hi Miika,
It looks good to me. I agree on moving to last call, pending further comments.

Spotted one typo in the new text:
s/Eeach/each/ local address candidate MUST ...

-Jeff

On 2/1/17, 3:14 AM, "Hipsec on behalf of Miika Komu" <hipsec-boun...@ietf.org on 
behalf of miika.k...@ericsson.com> wrote:

Hi,

as you can see the diff link below, this version includes some minor
editorial nits, but also some additional text in this section:

4.2. Transport Address Candidate Gathering

The priority and RTO calculation formulas from the ICE specification are
repeated here.

Unless there are further comments, I would suggest moving the draft to
last call.

On 02/01/2017 12:58 PM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the Host Identity Protocol of the IETF.
>
> Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
> Authors : Ari Keranen
>   Jan Melén
    >   Miika Komu
>Filename: draft-ietf-hip-native-nat-traversal-15.txt
>Pages   : 52
>Date: 2017-02-01
>
> Abstract:
>This document specifies a new Network Address Translator (NAT)
>traversal mode for the Host Identity Protocol (HIP).  The new mode is
>based on the Interactive Connectivity Establishment (ICE) methodology
>and UDP encapsulation of data and signaling traffic.  The main
>difference from the previously specified modes is the use of HIP
>messages for all NAT traversal procedures.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-15
>
>
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>

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




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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-15.txt

[Miika Komu]

Hi,

as you can see the diff link below, this version includes some minor 
editorial nits, but also some additional text in this section:


4.2. Transport Address Candidate Gathering

The priority and RTO calculation formulas from the ICE specification are 
repeated here.


Unless there are further comments, I would suggest moving the draft to 
last call.


On 02/01/2017 12:58 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
Authors : Ari Keranen
  Jan Melén
  Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-15.txt
Pages   : 52
Date: 2017-02-01

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



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

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-14.txt

[Miika Komu]

Hi Robert,

 

yes, mobility support is specified in the draft.

 

From: Robert Moskowitz [mailto:r...@htt-consult.com] 
Sent: Friday, November 25, 2016 6:33 AM
To: Miika Komu <miika.k...@ericsson.com>; hipsec@ietf.org
Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-14.txt

 

Miika,

Does this draft cover the use case where the mobile HIP device moves from
one NATed network to another.  Consider you are in Starbucks and move next
door to Dunkin Donuts.

Your device did this augmented BEX exchange in Starbucks.  You walk into DD
and your interface decides the signal from SB is too weak, but it has the
saved SSID for DD and switches (Gee I wonder if it could be the same 1918
address! oh boy.).  Would this work as a mobility update or a new BEX? 

On 11/24/2016 05:37 AM, Miika Komu wrote:

Hi, 

I read the latest version of the ICE specs. Based on this, I included more
details on ICE processing to the HIP NAT traversal draft. A quick summary of
the changes: 

* Introduced more details from ice-bis draft 
  * New terminology 
  * Aligned connectivity check procedure to match with ICE (3-way check is
now 4-way) 
  * Ta minimum value is now 5 ms (according to ICE bis) 
  * 4.9 Handoff: first update HIP relay to in order learn new server
reflexive locators 
  * New sections: 
 * 4.6.3.  Rules for Concluding Connectivity Checks 
 * 6.6.  Amplification attacks (new section) 
 * 6.7.  Attacks against Connectivity Checks and Candidate Gathering 
 * Appendix C.  Differences to ICE 
 * Appendix D.  Differences to Base Exchange and UPDATE procedures 
  * 7. IANA Considerations: added UNSAF considerations (references ICE) 
* updated references (some drafts are now RFCs) 

Feedback is welcome! For people already familiar with HIP, I'd recommend
reading "the diff to normal HIP" in section
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-14#appendix-
D

On 11/24/2016 10:32 AM, internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>  wrote: 




A New Internet-Draft is available from the on-line Internet-Drafts
directories. 
This draft is a work item of the Host Identity Protocol of the IETF. 

Title   : Native NAT Traversal Mode for the Host Identity
Protocol 
Authors : Ari Keranen 
  Jan Melén 
  Miika Komu 
Filename: draft-ietf-hip-native-nat-traversal-14.txt 
Pages   : 51 
Date: 2016-11-24 

Abstract: 
   This document specifies a new Network Address Translator (NAT) 
   traversal mode for the Host Identity Protocol (HIP).  The new mode is 
   based on the Interactive Connectivity Establishment (ICE) methodology 
   and UDP encapsulation of data and signaling traffic.  The main 
   difference from the previously specified modes is the use of HIP 
   messages for all NAT traversal procedures. 


The IETF datatracker status page for this draft is: 
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ 

There's also a htmlized version available at: 
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-14 

A diff from the previous version is available at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-14 


Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org. 

Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 

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







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

 



smime.p7s
Description: S/MIME cryptographic signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-14.txt

[Miika Komu]

Hi,

I read the latest version of the ICE specs. Based on this, I included 
more details on ICE processing to the HIP NAT traversal draft. A quick 
summary of the changes:


* Introduced more details from ice-bis draft
  * New terminology
  * Aligned connectivity check procedure to match with ICE (3-way check 
is now 4-way)

  * Ta minimum value is now 5 ms (according to ICE bis)
  * 4.9 Handoff: first update HIP relay to in order learn new server 
reflexive locators

  * New sections:
 * 4.6.3.  Rules for Concluding Connectivity Checks
 * 6.6.  Amplification attacks (new section)
 * 6.7.  Attacks against Connectivity Checks and Candidate Gathering
 * Appendix C.  Differences to ICE
 * Appendix D.  Differences to Base Exchange and UPDATE procedures
  * 7. IANA Considerations: added UNSAF considerations (references ICE)
* updated references (some drafts are now RFCs)

Feedback is welcome! For people already familiar with HIP, I'd recommend 
reading "the diff to normal HIP" in section 
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-14#appendix-D


On 11/24/2016 10:32 AM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
Authors : Ari Keranen
  Jan Melén
  Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-14.txt
Pages   : 51
Date: 2016-11-24

Abstract:
   This document specifies a new Network Address Translator (NAT)
   traversal mode for the Host Identity Protocol (HIP).  The new mode is
   based on the Interactive Connectivity Establishment (ICE) methodology
   and UDP encapsulation of data and signaling traffic.  The main
   difference from the previously specified modes is the use of HIP
   messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] RFC 4423bis and hip-dex

[Miika Komu]

Hi,

version 15 of RFC4423bis now references DEX.

On 10/27/2016 02:07 PM, Gonzalo Camarillo wrote:

Hi Miika,

the plan is to publish rfc4423bis last, after all other drafts in our
charter (including HIP DEX) have been published. So, this would not have
any influence in the planned queue.

Cheers,

Gonzalo

On 27/10/2016 1:57 PM, Miika Komu wrote:

Hi Gonzalo,

On 10/21/2016 10:28 AM, Gonzalo Camarillo wrote:

Bob, Miika,

RFC 4423bis does not reference the hip-dex draft. Should it?

https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14


we can add it if needed. The only problem is that we should push back
the 4423bis draft in the IETF queue since dex creates an additional
dependency.





smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] RFC 4423bis and hip-dex

[Miika Komu]

Hi Gonzalo,

On 10/21/2016 10:28 AM, Gonzalo Camarillo wrote:

Bob, Miika,

RFC 4423bis does not reference the hip-dex draft. Should it?

https://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-14


we can add it if needed. The only problem is that we should push back 
the 4423bis draft in the IETF queue since dex creates an additional 
dependency.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Relaying to non-hip aware servers

[Miika Komu]

Hi Robert,

On 09/27/2016 04:46 PM, Robert Moskowitz wrote:

Where did we describe connections from a mobile hip-aware host to a
legacy non-HIP 'stable' server.

I thought it was HIPBONE (as it is not what HIP nat traversal is about),
but I am not seeing this function there.

Basically, the Mobile host has its HIP SA with a relay that decapsulates
the ESP traffic onto legacy Internet.

This can cause some nasty routing scenarios unless the HIP host can
treat a group of relays as multihome interfaces or the like and use the
best relay for any connection.  Which would drive TCP/UDP crazy though?

I recall through the window, darkly, that we had these discussions. But
my search foo is weak and I am not finding them.


proxy HIP:

https://tools.ietf.org/html/draft-melen-hip-proxy-02
https://tools.ietf.org/html/draft-irtf-hiprg-proxies-05



smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis

[Miika Komu]

Hi,

On 09/27/2016 03:56 AM, Robert Moskowitz wrote:



On 09/26/2016 09:08 AM, Miika Komu wrote:

Hi,

On 09/16/2016 02:45 PM, Robert Moskowitz wrote:



On 09/16/2016 06:57 AM, Tom Henderson wrote:




On Thu, 15 Sep 2016, Robert Moskowitz wrote:


5206-bis specifies how to user RVS for the 'double-jump' mobility
problem.

3.2.3 1) says:

1. The mobile host sending an UPDATE to the peer, and not receiving
an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the
peer, if such a server is known.

But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC
parameters and it had created a VIA_RVS parameter to send in the R1.


Yes, but the responder may not know the initiator's RVS even if the
the responder's RVS was used, and it also may be the case that neither
host's RVS was involved in the session setup.


I see now.  As currently speced, R has no way of learning I's RVS. The
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet
for mobility support.

"If you every want to get back to me, I can always be reached at this
number".


do you actually need the initiator's RVS for double jump? I think the
responder's RVS is enough.


Then the Initiator's UPDATE must be successful before the Responder can
perform its UPDATE successfully.  This way they can operate in parallel.


I see, you really want to avoid packets being dropped.


This VIA_RVS provides the knowledge and locator of the peer's RVS.

In fact an aggressive mobility UPDATE would be sent simultaneously to
the host and its RVS.  If the host had not moved itself, it gets both
and drops the one from the RVS.


I believe that Baris Boyvat on the InfraHIP project was looking a
while back at such an approach to fast mobility; it was called
'shotgun' approach to mobility and multihoming (try all candidates
simultaneously), if I remember correctly.


Yes, the idea was to send I1 (or UPDATE) through all the available
address pairs, but I think the idea is now achieved in a more
controlled way in draft-ietf-hip-native-nat-traversal-13


I will look at that.  But what if there is no NATs to traverse? That
there are 2+ interfaces, all native IPv6?

But I will review nat-traversal.


Basically the nat-traversal draft is about connectivity checks (that 
traverse NATs), nothing much IPv4 specific there. Feedback is still welcome.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi René,

On 09/11/2016 11:06 PM, René Hummen wrote:

Hello Miika,

going through your email again, I saw a total of four suggestions.

Three of them refer to imprecisions in the text of RFC 7401 (which I
copy/pasted for HIP DEX). There, I understood that consistency with RFC
7401 has a higher priority than only fixing your comments for HIP DEX,
but keeping the text as is for RFC 7401. This means, I will not modify
the text in the HIP DEX draft. Is this also your intention?


yes, 7401 takes precedence over my comments.


The last remaining issue is related to the UPDATE message and the
rekeying procedure (Section 6.10.). Here, I added the following
paragraph for clarification purposes:

   [RFC7402] specifies the rekeying of an existing HIP SA using the
   UPDATE message.  This rekeying procedure can also be used with HIP
   DEX.  However, where rekeying involves a new Diffie-Hellman key
   exchange, HIP DEX peers MUST establish a new connection in order to
   create a new Pair-wise Key SA due to the use of static ECDH key-pairs
   with HIP DEX.

Does this fix your issue?


Yes. I assume you mean a new HIP association with connection.


BR
René



On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <miika.k...@ericsson.com
<mailto:miika.k...@ericsson.com>> wrote:

Hi,

On 06/03/2016 02:20 PM, René Hummen wrote:

This is part 3 of 3.


I am fine with your fixes. Some comments below.

On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu
<miika.k...@ericsson.com <mailto:miika.k...@ericsson.com>
<mailto:miika.k...@ericsson.com
<mailto:miika.k...@ericsson.com>>> wrote:

> [...]

 > 6.2.1.  CMAC Calculation
 >
 > [...]
 >
 >
 > 5.  Set Checksum and Header Length fields in the HIP
header to
 > original values.  Note that the Checksum and Length fields
 > contain incorrect values after this step.

I guess also the values following HIP_MAC should be restored
since
they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
that follow it with greater Type value, saving the
contents if
they will be needed later."

The question is whether we want to fix the description for HIP
DEX or to
keep things as they are for consistency reasons. In the former
case, I
would prefer to completely rewrite the verification procedure to
work on
the received packet without removing any parameters. However, we
should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.


Latter option works for me too.

 > The CKDF-Extract function is the following operation:
 >
 > CKDF-Extract(I, IKM, info) -> PRK

What does the arrow operator signify? I thought that it
produces PRK,
but PRK is actually defined below.


The arrow is part of a basic mathematical function definition.
So yes,
PRK is the output (domain), but we still need to give it a
proper name.
I changed the artwork to clearly point out the inputs and outputs.


Thanks, it is now better.

Please check this section again in the updated version and get
back to
me if the above changes do not sufficiently help your understanding.


It is good now, thanks!

 > Llength of output keying material in octets
 >  (<= 255*RHASH_len/8)
 > |denotes the concatenation
 >
 > The output keying material OKM is calculated as follows:
 >
 > N   =  ceil(L/RHASH_len/8)
 > T   =  T(1) | T(2) | T(3) | ... | T(N)
 > OKM =  first L octets of T
 >
 > where
 >
 > T(0) = empty string (zero length)
 > T(1) = CMAC(PRK, T(0) | info | 0x01)
 > T(2) = CMAC(PRK, T(1) | info | 0x02)
 > T(3) = CMAC(PRK, T(2) | info | 0x03)
 > ...

The Expand was a bit more clear, but still didn't understand
how to
get to the
Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual oper

Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis

[Miika Komu]

Hi,

On 09/16/2016 02:45 PM, Robert Moskowitz wrote:



On 09/16/2016 06:57 AM, Tom Henderson wrote:




On Thu, 15 Sep 2016, Robert Moskowitz wrote:


5206-bis specifies how to user RVS for the 'double-jump' mobility
problem.

3.2.3 1) says:

1. The mobile host sending an UPDATE to the peer, and not receiving
an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the
peer, if such a server is known.

But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC
parameters and it had created a VIA_RVS parameter to send in the R1.


Yes, but the responder may not know the initiator's RVS even if the
the responder's RVS was used, and it also may be the case that neither
host's RVS was involved in the session setup.


I see now.  As currently speced, R has no way of learning I's RVS. The
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet
for mobility support.

"If you every want to get back to me, I can always be reached at this
number".


do you actually need the initiator's RVS for double jump? I think the 
responder's RVS is enough.



This VIA_RVS provides the knowledge and locator of the peer's RVS.

In fact an aggressive mobility UPDATE would be sent simultaneously to
the host and its RVS.  If the host had not moved itself, it gets both
and drops the one from the RVS.


I believe that Baris Boyvat on the InfraHIP project was looking a
while back at such an approach to fast mobility; it was called
'shotgun' approach to mobility and multihoming (try all candidates
simultaneously), if I remember correctly.


Yes, the idea was to send I1 (or UPDATE) through all the available 
address pairs, but I think the idea is now achieved in a more controlled 
way in draft-ietf-hip-native-nat-traversal-13




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Stephen Farrell's Discuss on draft-ietf-hip-rfc5203-bis-10: (with DISCUSS and COMMENT)

[Miika Komu]

Hi,

the proposed changes seemed fine at least to me.

P.S. Sorry, got back from holidays this week.

On 08/05/2016 03:42 AM, Julien Laganier wrote:

Hi Stephen,

FYI I've implemented the proposed change in the last draft revision.

Best,

--julien

On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell
 wrote:


Hiya,

That'd be fine for clearing my discuss.

I'd encourage you to also get feedback from the WG though as I
don't think I've ever seen a list of cert handling errors that
was correct first time around:-)

Cheers,
S.



On 20/07/16 16:11, Julien Laganier wrote:

Hi Stephen,

Thanks for reviewing the document.

I think there would be value in making the cause of certificate error
explicit. Would the following change be acceptable?

OLD:

   If the certificate in the parameter is not accepted, the registrar
   MUST reject the corresponding registrations with Failure Type [IANA
   TBD] (Invalid certificate).

NEW:

   If the certificate in the parameter is not accepted, the registrar
   MUST reject the corresponding registrations with the appropriate
   Failure Type:
   [IANA TBD] (Bad certificate): The certificate is corrupt, contains
invalid signatures, etc.
   [IANA TBD] (Unsupported certificate): The certificate is of an
unsupported type.
   [IANA TBD] (Certificate expired): The certificate is no longer valid.
   [IANA TBD] (Certificate other): The certificate could not be
validated for some unspecified reason.
   [IANA TBD] (Unknown CA): The issuing CA certificate could not be
located or is not trusted.

Please let us know.

Best,

--julien




On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell
 wrote:

Stephen Farrell has entered the following ballot position for
draft-ietf-hip-rfc5203-bis-10: 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-rfc5203-bis/



--
DISCUSS:
--


3.3 - This fails to distinguish between an invalid
certificate (e.g. bad signature, unknown signer) and one
that is valid, but is not acceptable for this purpose.  I
don't get why that is ok for HIP, can you explain?  If it
is ok, I think you need to say so. If it is not ok (as I'd
suspect) then you appear to need to change text or one more
new error code.


--
COMMENT:
--


Section 7 - I'm fine that this doesn't repeat stuff
from 5203, but a sentence saying to go look there too
would maybe be good. (I'm not sure if that would fix
Alexey's discuss or not. If not, then ignore me and
just talk to him about his discuss.)






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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt

[Miika Komu]

Hi Jeff,

On 06/30/2016 07:08 PM, Jeff Ahrenholz wrote:

Miika,


On 6/30/16, 1:12 AM, "Miika Komu" <miika.k...@ericsson.com> wrote:

Is it actually a problem for the Responder that two different Initiators
happen to claim different SPIs? The Initiators have different IP
addresses (or at least UDP ports if they are behind the same NAT).


You’re right, it seems like it is not a problem for the Responder since there 
are different IP/ports.


Ok. I added the following sentence (separated with starts) to the draft:

"In first case, the SPI collision problem occurs when two
Initiators run a base exchange to the same Responder (i.e. registered 
host), and both the Initiators claim the

same inbound SPI. ***This is not a problem for Responder
since the two Initiators can be distinguished by their transport
addresses. *** However, it is an issue for the data relay
because the it cannot demultiplex packets from the Initiator
to the correct Responder."


It is a problem for the data relay, so the text says:

"Upon receiving an I2 with a colliding SPI, the Responder MUST not
include the relayed address in the R2 message because the data relay
would not be able demultiplex the related ESP packet to the correct
Initiator."


Does this mean the Responder should not even send the R2 message upon collision?


Since we agreed that it is not an (IPsec) problem for the Responder, the 
answer is "no". The text says that the Responder can send R2 but without 
the locator of the data relay because the data relay would be confused 
about the conflicting SPIs.



The draft also says this:

  “The described
collision scenario can be avoided if the Responder delivers a new
relayed address candidate upon SPI collisions.  Each relayed address
has a separate UDP port reserved to it, so the relay can demultiplex
properly conflicting SPIs of the Initiators based on the SPI and port
number towards the correct Responder.”

What if the Responder sends the R2 message (established state)  and then 
immediately follows with an UPDATE packet to initiate a rekey?
The rekey would cause both sides to select new SPI values.


Good catch, added:

"The same applies also the handover procedure; the
registered host MUST NOT include the relayed address candidate
when sending its new locator set in an UPDATE to its peer if it would 
cause a SPI conflict with another peer."



Not sure what happens if you send the R2 without the relayed address -- proper 
state not created on the Initiator?


If NAT connectivity tests fail to set up a direct path, the indirect 
path through the data relay will be unavailable => no path for data traffic.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

On 02/23/2016 04:08 PM, Tom Henderson wrote:



On 02/16/2016 06:22 AM, Ari Keränen wrote:

Thank you for the review Tom! Please see below.


On 12/02/2016 11:54 PM, Tom Henderson wrote:

Gonzalo and all,

My understanding is that the WG reached consensus several years
ago that the standards-track NAT traversal variant would be the
native NAT traversal and not the RFC5770-based ICE/STUN/TURN
version.

I reviewed the above draft and noticed that it still contains
normative references to RFC5770 (pointers to material found
only in RFC5770) throughout, and contains RFC5770 as a
normative reference in Section 8.1.  It seems to me that the WG
ought to produce a specification that can stand alone from
RFC5770, because as it stands now, it seems to me that someone
implementing it would need to consult both drafts and may be
uncertain about what is still applicable from RFC5770.  For
example, is the UDP-ENCAPSULATION mode still valid?


Indeed this variant is the standards-track solution, but I think
it makes sense to not obsolete the RFC5770. For example, in some
scenario the STUN based solution could be better than native HIP
based. And also the UDP-ENCAPSULATION mode should be still valid.


ICE (RFC 5245) is also still listed as normative but it seems
to me that it should also be informative in this draft.


The details of e.g., how ICE checklists are used are defined in
RFC5245 so I think it needs to be normative.


I think it would be appropriate to just reference 5770 in the
Introduction, stating that this specification replaces RFC
5770 with a different mechanism than ICE/STUN/TURN, and then
try to avoid referencing 5770 from then on.


Avoiding RFC 5770 altogether would require lots of editorial work
with this draft for a questionable amount of benefit, so I think
it's better if we simply have it as normative reference. The
maturity level of 5770 (experimental) is an issue, but I think it
is possible - and makes sense - to make an exception here.


Ari, I have thought about this and it seems to me that there are two
issues to discuss.

There is a technical issue to resolve, which is whether the WG wants
to keep RFC5770 solutions as non-obsolete, and how to express these
options to future implementers.  I had thought that the WG position
was to drop support for STUN-based solutions, but you are suggesting
now to keep it active, perhaps as a MAY implement?   It seems to me
that the basic UDP-ENCAPSULATION mode should still be kept mandatory
since it is the basis for the other approach and is useful by
itself.

>

Then there is the editorial issue about how to meet IETF guidelines
on how things are cross-referenced and use of informative/normative
references, which seems to me risky at the moment (i.e., I am
anticipating a downstream reviewer expressing this same concern).
Plus there is the goal of making it clearer to implementers.


trying to recap your complete opinion... do you think the 
UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 
MAY? Or do you think the draft should just deprecate RFC5770?


Btw, RFC5770 is still a normative reference because we are redundantly 
explaining some parts of the RFC in the draft.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

On 02/16/2016 04:22 PM, Ari Keränen wrote:

Thank you for the review Tom! Please see below.


On 12/02/2016 11:54 PM, Tom Henderson wrote:

Gonzalo and all,

My understanding is that the WG reached consensus several years ago
that the standards-track NAT traversal variant would be the native
NAT traversal and not the RFC5770-based ICE/STUN/TURN version.

I reviewed the above draft and noticed that it still contains
normative references to RFC5770 (pointers to material found only in
RFC5770) throughout, and contains RFC5770 as a normative reference
in Section 8.1.  It seems to me that the WG ought to produce a
specification that can stand alone from RFC5770, because as it
stands now, it seems to me that someone implementing it would need
to consult both drafts and may be uncertain about what is still
applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
mode still valid?


Indeed this variant is the standards-track solution, but I think it
makes sense to not obsolete the RFC5770. For example, in some scenario
the STUN based solution could be better than native HIP based. And also
the UDP-ENCAPSULATION mode should be still valid.


the draft does not replace RFC5770, but offers a parallel/independent 
way to implement NAT traversal. UDP-ENCAPSULATION mode is still valid.



ICE (RFC 5245) is also still listed as normative but it seems to me
that it should also be informative in this draft.


The details of e.g., how ICE checklists are used are defined in RFC5245
so I think it needs to be normative.


You're right, and new ICE (rfc5245bis) is now normative.


I think it would be appropriate to just reference 5770 in the
Introduction, stating that this specification replaces RFC 5770
with a different mechanism than ICE/STUN/TURN, and then try to
avoid referencing 5770 from then on.


Avoiding RFC 5770 altogether would require lots of editorial work with
this draft for a questionable amount of benefit, so I think it's better
if we simply have it as normative reference. The maturity level of 5770
(experimental) is an issue, but I think it is possible - and makes sense
- to make an exception here.


The draft has been improved radically from the viewpoint of readability 
and it is more independent from RFC5770. The old draft is somehow more 
mature in the sense that it has been implemented and successfully 
interoperated. However, it is based on the old ICE specification that is 
going to be deprecated this year.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi Derek,

On 03/29/2016 02:51 AM, Derek Fawcus wrote:

On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote:

First he will look into adding clarifications to the existing draft
while still referencing the old RFC. If the group is not happy with the
readability after the editorial pass (or our AD does not finally let us
downref the old RFC), we can consider bringing material from the old RFC
directly into the new one.


Sorry,  that I'm quite late in looking at these,  but have been doing
so recently...

I have to say that I find the it difficult to decode simply because
of having to refer to 3 (the draft, 5770, 5245) plus possibly the
STUN/TURN docs at once.

I'd certainly find it easier to comprehend if the text from 5770 was
incorporated (suitably modified to account for not doing STUN/TURN)
within the draft.  That way the references to the significant pieces
of 5245 text would be easier to nail down.


done!


As it is,  I currently find it a bit like reading an Act of Parliament!

e.g. $3.8 Connectivity Checks
refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to
$5.7 of 5245 and $7 of 5245,  where the exceptions (use of UPDATE instead
of STUN) have to be applied to that $7 referencing 5389,  so possibly
I don't have to read 5389, since hopefully it would just be packet formats.


I would also like the group to comment on the following two proposals:

1) the draft will allow implementers to use HIP native relays only. In
addition, the use of STUN and TURN relays will be optional.


I'd suggest the draft be native only,  but say with an appendix referencing
5770 for use of STUN/TURN,  maybe indicating which bits of the 5770
to take heed of.


STUN is now optional, but just for determining the host's owns address 
candidates. Data relay must be used instead of TURN.



2) in addition to covering the base exchange, the draft will also cover
the mobility readdressing exchange.


Not having read that recently,  I can't really comment.


The mobility is now covered.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

FYI,

my original concerns are now addressed in the 12 version of the draft. 
Regarding to my last question on OSPI and ISPI, I think it is better to 
keep things as they are (i.e. it is not mandatory for the Initiator to 
even have a HIP relay). I discussed the topic with Ari and this follows 
better the ICE methodology.


On 02/22/2016 05:30 PM, Miika Komu wrote:

Hi Ari,

below is more detailed list of the nits and also some technical comments
about the protocol.

On 02/16/2016 04:01 PM, Ari Keränen wrote:

On 12/02/16 22:59, Miika Komu wrote:

Hi,

On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:

Hi,

I would like to start a WGLC on the following draft. This WGLC will end
on February 12th:

https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

Please, send your comments to this list.


in general, the draft should have a short intro to the NAT traversal
procedure and re-introduce some terms even though it all is specified in
RFC5770. This would make the draft a bit easier to read. I have also
some other nits which I'll send a bit later.


Thanks for the review Miika! Also Petri commented along the same lines.
We'll add some intro text to the draft to address this.


 > 2.  Terminology

I would repeat some of the terms used in RFC5770. Particularly these
would be useful:

* relayed address
* server reflexive candidate
* relayed candidate
* mapped address

They are used the text and it would be nice to make the draft a bit more
self-explanatory.

I would also suggest to explain the ICE term "permission" here.

 > 3.  Protocol Description

I would suggest to add a small intro here of the entire process
(registration, discovery of relay, base exchange, hole punching, ESP). A
picture similar to figure 1 in RFC5770 would be nice.

 > 3.1.  Relay Registration

 > Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has

at -> in

 > 3.2.  Forwarding Rules and Permissions
 >
 > Permissions are not required for the connectivity checks, but if a
 > relayed address is selected to be used for data, the registered host
 > MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
 > parameter (see Section 4.2) with the address of the peer and the
 > outbound and inbound SPI values the host is using with this peer.

PEER_PERMISSION is not a part of RFC5770, why is it introduced here?

The description is missing also the destination where this message is to
be sent (it is the relay).

 > 3.3.  Relaying UDP Encapsulated Data and Control Packets

 > When a host wants to send a HIP control packet (such as a
 > connectivity check packet) to a peer via the data relay, it MUST add

* wants -> intends (machines don't have a will, at least yet :)
* it -> ambiguous, should be "the host"
* via the *peer's* data relay, right? I mean both hosts may have their
own data relays.

 > send it to the data relay's address.  The data relay MUST send the

address of the data relay of the peer (right?)

 > When a host wants to send a UDP encapsulated ESP packet to a peer via
 > the data relay, it MUST have an active permission at the data relay
 > for the peer with the outbound SPI value it is using.

*peer* data relay

 > The host MUST send the UDP encapsulated ESP packet to the data
relay's address.

What host? Whose data relay?

* wants -> intends
* peer's data relay (right? please correct twice)

The third ("If the data relay..."), fourth (When a host) and fifth
("When the data relay...") paragraphs appear a bit of
redundant/overlapping, perhaps it is better to merge them together.

Please state the owner of the data relay (i.e. registered host) in all
cases. The data relay only relays data traffic to one way (to the
registered host), right?

 > 3.4.  Candidate Gathering

 > Gathering of candidates MAY also be performed like specified in

like -> as

 > 3.7.  Connectivity Check Pacing Negotiation

 > the check pacing negotiation -> the connectivity check pacing
negotiation

 > 3.8.  Connectivity Checks

 > [RFC5770] but instead of STUN packets, the connectivity checks are

..., but instead of STUN packets,,,

 > checklist and start check transactions every Ta milliseconds as long

..start *to* check..

 > The UPDATE packets that acknowledge a
 > connectivity check requests MUST be sent from the same address that
 > received the check and to the same address where the check was
 > received from.

it would be easier to read this in singular form rather than plural:

An/Any UPDATE packet that acknowledges a connectivity check request MUST
originate from the same address that
was used to receive the check and destined to the same address where the
check was
received from.

(please note that I changed the wording a bit)

 > The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS
 > parameter with the port, protocol, and IP address of the address
 > 

Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-12.txt

[Miika Komu]

Hi,

high-level changes are as follows:

  * The new draft version follows the ice-bis version, so I removed 
aggressive nomination
  * Clarifications in the subsections in section 4.12. Relaying 
Considerations

  * Fixed some nits

Open questions:

  * What should do with compatibility with RFC 6078 (HICCUPS)
  * Connectivity tests should be skipped unless ESP_TRANSFORM is 
negotiated?

  * Steps 5-6 could be skipped in the handoff sequence? See fig. 6.
  * 4.12.3.  Handling Conflicting SPI Values
* Should the Responder send a notify on SPI collision?
* Removed text about registering with multiple addresses because I 
think this does not work with HIP (or at least, requires multihoming)
  * Lower the connectivity test pacing value from 20 ms to 2 ms (as in 
the ice-bis specs) in section 4.4?


On 06/23/2016 05:12 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol of the IETF.

 Title   : Native NAT Traversal Mode for the Host Identity 
Protocol
 Authors : Ari Keranen
   Jan Melén
   Miika Komu
Filename: draft-ietf-hip-native-nat-traversal-12.txt
Pages   : 44
Date: 2016-06-23

Abstract:
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP).  The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic.  The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi,

On 06/03/2016 02:20 PM, René Hummen wrote:

This is part 3 of 3.


I am fine with your fixes. Some comments below.


On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <miika.k...@ericsson.com
<mailto:miika.k...@ericsson.com>> wrote:

> [...]

 > 6.2.1.  CMAC Calculation
 >
 > [...]
 >
 >
 > 5.  Set Checksum and Header Length fields in the HIP header to
 > original values.  Note that the Checksum and Length fields
 > contain incorrect values after this step.

I guess also the values following HIP_MAC should be restored since
they were wiped in the step 2.


I also found this description a bit imprecise, but it is taken from
RFC7401. Step 2 already hints at the fact that parameters following
HIP_MAC may still be of interest:
"Remove the HIP_MAC parameter, as well as all other parameters
that follow it with greater Type value, saving the contents if
they will be needed later."

The question is whether we want to fix the description for HIP DEX or to
keep things as they are for consistency reasons. In the former case, I
would prefer to completely rewrite the verification procedure to work on
the received packet without removing any parameters. However, we should
then probably also post an errata to RFC7401. If there are no stong
opinions about that, I would go for the latter option.


Latter option works for me too.


 > The CKDF-Extract function is the following operation:
 >
 > CKDF-Extract(I, IKM, info) -> PRK

What does the arrow operator signify? I thought that it produces PRK,
but PRK is actually defined below.


The arrow is part of a basic mathematical function definition. So yes,
PRK is the output (domain), but we still need to give it a proper name.
I changed the artwork to clearly point out the inputs and outputs.


Thanks, it is now better.


Please check this section again in the updated version and get back to
me if the above changes do not sufficiently help your understanding.


It is good now, thanks!


 > Llength of output keying material in octets
 >  (<= 255*RHASH_len/8)
 > |denotes the concatenation
 >
 > The output keying material OKM is calculated as follows:
 >
 > N   =  ceil(L/RHASH_len/8)
 > T   =  T(1) | T(2) | T(3) | ... | T(N)
 > OKM =  first L octets of T
 >
 > where
 >
 > T(0) = empty string (zero length)
 > T(1) = CMAC(PRK, T(0) | info | 0x01)
 > T(2) = CMAC(PRK, T(1) | info | 0x02)
 > T(3) = CMAC(PRK, T(2) | info | 0x03)
 > ...

The Expand was a bit more clear, but still didn't understand how to
get to the
Expanded key material due the arrow notation.


Ok, let's clarify this as several comments are related to the arrow
notation. For the function definition we use the mathematical arrow
notation (same as RFC 5869) and for the actual opertation we use the
equals sign (same as RFC 5869). In the end, they denote the same thing:
"assign X to Y".


Ok, this is what I guessed too.


 > (where the constant concatenated to the end of each T(n) is a
 > single octet.)

Is there a max value?


I am not sure what you mean here. If you refer to the N in T(N) then it
is defined above as N = ceil(L/RHASH_len/8).


Yes, I asked about the maximum value for N (which depends on L), but 
never mind.



 > 8.   The R1 packet may have the A-bit set - in this case, the system
 > MAY choose to refuse it by dropping the R1 packet and returning
 > to state UNASSOCIATED.  The system SHOULD consider dropping the
 > R1 packet only if it used a NULL HIT in the I1 packet.

I didn't understand the logic in the last sentence.


Someone must have had a reason for this recommendation, but that someone
wasn't me. This is text from RFC7401. Any suggestions how to proceed?


Fix similarly as the other RFC7401 issue in the beginning of this email.


 > 6.7.  Processing Incoming I2 Packets
 >
 > [...]
 >
 > 5.   If the system's state machine is in the I2-SENT state, the
 > system MUST make a comparison between its local and sender's
 > HITs (similarly as in Section 6.3).  If the local HIT is smaller
 > than the sender's HIT, it should drop the I2 packet, use the
 > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce
 > #I from the R1 packet received earlier, and get the local
 > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J
 > from the I2 packet sent to the peer earlier.  Otherwise, the
 > system should process the received I2 packet and drop any
 > previously derived Diffie-Hellman keying material Kij and
 > ENCRYPTED_KEY keying material it might have generated upon
 > sending the I2 packet previously.  The peer 

Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi Rene,

On 06/01/2016 03:08 PM, René Hummen wrote:

This is part 2. More to come...


I am fine with your fixes for part 2.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10

[Miika Komu]

Hi Tom,

your changes are fine, thanks for the quick response.

On 04/19/2016 08:11 PM, Tom Henderson wrote:

Hi Miika, thanks for the review; some responses are inline below.  I will 
continue later in a second message.

- Tom

On 04/17/2016 01:26 PM, Miika Komu wrote:

Hi,

I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape.
Below are a few nits.

  > 3.1.  Operating Environment
  >
  > [...]
  >
  > Consider next a mobility event, in which a host moves to another IP
  > address.  Two things must occur in this case.  First, the peer must
  > be notified of the address change using a HIP UPDATE message.
  > Second, each host must change its local bindings at the HIP sublayer
  > (new IP addresses).  It may be that both the SPIs and IP addresses
  > are changed simultaneously in a single UPDATE; the protocol described
  > herein supports this.  However, elements of procedure to recover from

I think simultaneous mobility is covered as already mentioned in the intro?


Fixed



  > 3.2.3.  Mobility messaging through rendezvous server
  >
  > 3.  A host receiving an UPDATE packet MUST be prepared to process the
  > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS
  > parameter in the UPDATE reply that contains the ACK of the UPDATE
  > SEQ.

(I would add that the return routability test should be invoked to the
end-host's addresses rather than the ones in VIA_RVS)


I added another numbered item:

   An initiator receiving a VIA_RVS in the UPDATE reply should
   initiate address reachability tests (described later in this
   document) towards the end host's address and not towards the
   address included in the VIA_RVS.



  > 4.  This scenario requires that hosts using rendezvous servers also
  > take steps to update their current address bindings with their
  > rendezvous server upon a mobility event.
  > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the
  > rendezvous server with a client host's new address.
  > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may
  > send a REG_REQUEST in either an I2 packet (if there is no active
  > association) or an UPDATE packet (if such association exists).

(Maybe this should have been actually step 0)


It really should not be in the sequential list; I moved it outside of the list.


  > The procedures described in [I-D.ietf-hip-rfc5203-bis] for
  > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server
  > apply also to this mobility scenario.

This was a bit vague, how?


Here is how I clarified it; do you agree?

   According to procedures described in [I-D.ietf-hip-rfc5203-bis],
   if a mobile host
   has an active registration, it may use mobility updates specified
   herein, within the context of that association, to readdress the
   association.



  > 3.2.4.  Network Renumbering
  >
  > It is expected that IPv6 networks will be renumbered much more often
  > than most IPv4 networks.  From an end-host point of view, network
  > renumbering is similar to mobility.

...and?


added " , and  procedures described herein also apply to notify a peer of
 a changed address."


  > 3.3.  Other Considerations
  >
  > 3.3.1.  Address Verification
  >
  > When a HIP host receives a set of locators from another HIP host in a
  > LOCATOR_SET, it does not necessarily know whether the other host is
  > actually reachable at the claimed addresses.  In fact, a malicious
  > peer host may be intentionally giving bogus addresses in order to
  > cause a packet flood towards the target addresses [RFC4225].
  > Therefore, the HIP host must first check that the peer is reachable
  > at the new address.
  >
  > An additional potential benefit of performing address verification is
  > to allow middleboxes in the network along the new path to obtain the
  > peer host's inbound SPI.
  >
  > Address verification is implemented by the challenger sending some
  > piece of unguessable information to the new address, and waiting for
  > some acknowledgment from the Responder that indicates reception of
  > the information at the new address.  This may include the exchange of
  > a nonce, or the generation of a new SPI and observation of data
  > arriving on the new SPI.

I suggest would move the second paragraph after the third one.


OK



  > 3.3.2.  Credit-Based Authorization
  >
  > On this basis, rather than eliminating malicious packet redirection
  > in the first place, Credit-Based Authorization prevents
  > amplifications.  This is accomplished by limiting the data a host can
  > send to an unverified address of a peer by the data recently received
  > from that peer.  Redirection-based flooding attacks thus become less
  > attractive than,

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

On 03/29/2016 02:51 AM, Derek Fawcus wrote:

On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote:

First he will look into adding clarifications to the existing draft
while still referencing the old RFC. If the group is not happy with the
readability after the editorial pass (or our AD does not finally let us
downref the old RFC), we can consider bringing material from the old RFC
directly into the new one.


Sorry,  that I'm quite late in looking at these,  but have been doing
so recently...

I have to say that I find the it difficult to decode simply because
of having to refer to 3 (the draft, 5770, 5245) plus possibly the
STUN/TURN docs at once.

I'd certainly find it easier to comprehend if the text from 5770 was
incorporated (suitably modified to account for not doing STUN/TURN)
within the draft.  That way the references to the significant pieces
of 5245 text would be easier to nail down.

As it is,  I currently find it a bit like reading an Act of Parliament!

e.g. $3.8 Connectivity Checks
refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to
$5.7 of 5245 and $7 of 5245,  where the exceptions (use of UPDATE instead
of STUN) have to be applied to that $7 referencing 5389,  so possibly
I don't have to read 5389, since hopefully it would just be packet formats.


I would also like the group to comment on the following two proposals:

1) the draft will allow implementers to use HIP native relays only. In
addition, the use of STUN and TURN relays will be optional.


I'd suggest the draft be native only,  but say with an appendix referencing
5770 for use of STUN/TURN,  maybe indicating which bits of the 5770
to take heed of.


2) in addition to covering the base exchange, the draft will also cover
the mobility readdressing exchange.


Not having read that recently,  I can't really comment.


I am going to join the author list and help to improve the draft 
according the comments on the mailing list.


Another change we plan to do is to adjust the current specification to 
new ice-bis recommendations (smaller delays, for instance). This will 
cause some delays because it's not yet an RFC.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi Ari,

On 04/10/2016 09:28 AM, Ari Keränen wrote:

3.2.  Forwarding Rules and Permissions
> >
> >Permissions are not required for the connectivity checks, but if a
> >relayed address is selected to be used for data, the registered host
> >MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
> >parameter (see Section 4.2) with the address of the peer and the
> >outbound and inbound SPI values the host is using with this peer.

>
>PEER_PERMISSION is not a part of RFC5770, why is it introduced here?

Because that's needed for the data relay in order to have the same 
functionality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to allow 
only explicitly singled peers to connect to the host via relay.


I would also suggest mentioning that PEER_PERMISSION must include a SEQ 
parameter to make sure that we have retransmissions (data relay sends an 
ACK).




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

[Hipsec] A review of draft-ietf-hip-dex-02.txt

[Miika Komu]

Hi,

> 1.1.  The HIP Diet EXchange (DEX)

> Data packets start to flow after the 4th packet.  The 3rd and 4th HIP
> packets may carry data payload in the future.  However, the details
> of this may be defined later.

Similarly as in RFC7401, data packets start to flow...

(I guess you could also mention RFC6078 as another further work item)

> An existing HIP association can be updated with the update mechanism
> defined in [RFC7401].  Likewise, the association can be torn down
> with the defined closing mechanism for HIPv2 if it is no longer
> needed.  HIP DEX thereby omits the HIP_SIGNATURE parameters of the
> original HIPv2 specification.

Why "thereby"? I don't see the connection.

> HIP DEX does not have the option to encrypt the Host Identity of the
> Initiator in the 3rd packet.  The Responder's Host Identity also is
> not protected.  Thus, contrary to HIPv2, there is no attempt at
> anonymity.

The anonymous bit still exists, so I suggest changing the wording:

there is no attempt at anonymity -> such Responder anonymity is not 
preserved in HIP DEX.


> 2.1.  Requirements Terminology

In section 6.3, you are introduce also -> notation, which was
not explained.

> 2.3.  Definitions

I suggest to add also the definitions of both MAC and CMAC because they
are used throughout the document. They are also used in this section.

> 3.1.  Host Identity Tag (HIT)

Just thinking aloud... should a DEX HIT have a different context ID?
Probably not.

> 4.1.  Creating a HIP Association

> The HIP Diet EXchange serves to manage the establishment of state
> between an Initiator and a Responder.  The first packet, I1,
> initiates the exchange, and the last three packets, R1, I2, and R2,
> constitute an authenticated Diffie-Hellman [DH76] key exchange for
> the Master Key SA generation.  This Master Key SA is used by the
> Initiator and the Responder to wrap secret keying material in the I2
> and R2 packets.  Based on the exchanged keying material, the peers
> then derive a Pair-wise Key SA if cryptographic keys are needed,
> e.g., for ESP-based protection of user data.

(Suggest replacing "user data" with e.g. "data plane" in the entire
document since you're talking about machines (sensors) that may not
have a user)

> In the I2 packet, the Initiator MUST display the solution to the
> received puzzle.  Without a correct solution, the I2 packet is
> discarded.  The I2 also contains a key wrap parameter that carries a
> secret keying material of the Initiator.  This keying material is
> only half the final session key.  The packet is authenticated by the
> sender (Initiator) via a MAC.

...half *of* the...

> The R2 packet acknowledges the receipt of the I2 packet and completes
> the handshake.  The R2 contains a key wrap parameter that carries the
> rest of the keying material of the Responder.  The packet is
> authenticated by the sender (Responder) via a MAC.

key wrap parameter -> parameter with encrypted contents

> 4.1.1.  HIP Puzzle Mechanism
>
> The puzzle mechanism enables a Responder to immediately reject an I2
> packet if it does not contain a valid puzzle solution.  To verify the
> puzzle solution, the Responder only has to compute a single CMAC
> operation.  After a successful puzzle verification, the Responder can
> securely create session-specific state and perform CPU-intensive
> operations such as a Diffie-Hellman key generation.  By varying the
> difficulty of the puzzle, the Responder can frustrate CPU or memory
> targeted DoS attacks.

...can frustrate *an Initiator*...

> Conceptually, the puzzle mechanism in HIP DEX is the same as in
> HIPv2.  Hence, this document refers to Sections 4.1.1 and 4.1.2 in
> [RFC7401] for more detailed information about the employed mechanism.
> Notably, the only difference between the puzzle mechanism in HIP DEX
> and HIPv2 is that HIP DEX uses CMAC instead of a hash function for
> solving and verifying a puzzle.  The implications of this change on
> the puzzle implementation are discussed in Section 6.1.

The other difference is mentioned in section 6.1:

"The only exceptions are that HIP DEX does not use pre-computation of
R1 packets and that RHASH is set to CMAC.  As a result, the pre-
computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX."

> 4.1.2.1.  HIP DEX Retransmission Mechanism

> The potentially high processing time of an I2 packet at a (resource-
> constrained) Responder may cause premature retransmissions if the
> time required for I2 transmission and processing exceeds the RTT-
> based retransmission timeout.  Thus, the Initiator should also take
> the processing time of the I2 packet at the Responder into account
> for retransmission purposes.  To this end, the Responder MAY notify
> the Initiator about the anticipated delay once the puzzle solution
> was successfully verified and if the remaining I2 packet processing
> incurs a high processing delay.  The Responder MAY therefore send a
> NOTIFY packet (see Section 5.3.6. in 

Re: [Hipsec] IPCOMP support in HIP

[Miika Komu]

Hi,

I guess it could be a new "IPCOMP" transform similar to the ESP transform:

https://tools.ietf.org/html/rfc7402#section-5.1.2

I think R1-I2 would be enough, no need to confirm it in R2, similarly as 
with ESP transform:


https://tools.ietf.org/html/rfc7402#section-5.2.1

On 03/10/2016 03:29 PM, Robert Moskowitz wrote:

I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing
compression.  How did I miss that?  It should have been included in 7402
as an option within ESP.

I will figure out a way to get it into some RFC, but perhaps a little
hashing out how it would work is called for first:

IPCOMP parameter is a list.  The parameter number is higher than ESP;
something like 4111.

RFC 3173 defines the Compression Parameter Index as 2 bytes, so that
would be the size of the values in the list.

R1 would have a list of supported IPCOMP algorithms.
I2 would have the selected algorithm, or a value of ZERO if none.
R2 would have the confirmed value.

NOTIFY could be used to set up IPCOMP (or change it) at a later time.

Comments?


On 03/09/2016 10:20 AM, Robert Moskowitz wrote:

Why did we not create a parameter to negotiate IPCOMP (currently RFC
3173)?

In IKEv2 it is negotiated in NOTIFY messages, not the basic exchange
and becomes part of the daughter SA(s).

On contrained networks, IPCOMP could well be of value.  Also if HIP is
used to establish the SAs for SSE (draft-moskowitz-sse-02.txt) and the
SSE payload is XML, then IPCOMP (or some variant tbd) may be a good
thing.

So

Again, why no IPCOMP parameter?

IPCOMP parameter handled like ESP parameter or like in IKEv2?

How to add an IPCOMP parameter?  If I write a draft for a Generic
Protocol Compression, I can include a section that defines an
IPCOMP/GPCOMP parameter.  Or I can add it to DEX (don' want to add
that at this point, EC25519 fits, IPCOMP is expanding the protocol).

Comments?


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



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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi Ari,

below is more detailed list of the nits and also some technical comments 
about the protocol.


On 02/16/2016 04:01 PM, Ari Keränen wrote:

On 12/02/16 22:59, Miika Komu wrote:

Hi,

On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:

Hi,

I would like to start a WGLC on the following draft. This WGLC will end
on February 12th:

https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

Please, send your comments to this list.


in general, the draft should have a short intro to the NAT traversal
procedure and re-introduce some terms even though it all is specified in
RFC5770. This would make the draft a bit easier to read. I have also
some other nits which I'll send a bit later.


Thanks for the review Miika! Also Petri commented along the same lines.
We'll add some intro text to the draft to address this.


> 2.  Terminology

I would repeat some of the terms used in RFC5770. Particularly these 
would be useful:


* relayed address
* server reflexive candidate
* relayed candidate
* mapped address

They are used the text and it would be nice to make the draft a bit more 
self-explanatory.


I would also suggest to explain the ICE term "permission" here.

> 3.  Protocol Description

I would suggest to add a small intro here of the entire process 
(registration, discovery of relay, base exchange, hole punching, ESP). A 
picture similar to figure 1 in RFC5770 would be nice.


> 3.1.  Relay Registration

> Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has

at -> in

> 3.2.  Forwarding Rules and Permissions
>
> Permissions are not required for the connectivity checks, but if a
> relayed address is selected to be used for data, the registered host
> MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
> parameter (see Section 4.2) with the address of the peer and the
> outbound and inbound SPI values the host is using with this peer.

PEER_PERMISSION is not a part of RFC5770, why is it introduced here?

The description is missing also the destination where this message is to 
be sent (it is the relay).


> 3.3.  Relaying UDP Encapsulated Data and Control Packets

> When a host wants to send a HIP control packet (such as a
> connectivity check packet) to a peer via the data relay, it MUST add

* wants -> intends (machines don't have a will, at least yet :)
* it -> ambiguous, should be "the host"
* via the *peer's* data relay, right? I mean both hosts may have their 
own data relays.


> send it to the data relay's address.  The data relay MUST send the

address of the data relay of the peer (right?)

> When a host wants to send a UDP encapsulated ESP packet to a peer via
> the data relay, it MUST have an active permission at the data relay
> for the peer with the outbound SPI value it is using.

*peer* data relay

> The host MUST send the UDP encapsulated ESP packet to the data 
relay's address.


What host? Whose data relay?

* wants -> intends
* peer's data relay (right? please correct twice)

The third ("If the data relay..."), fourth (When a host) and fifth 
("When the data relay...") paragraphs appear a bit of 
redundant/overlapping, perhaps it is better to merge them together.


Please state the owner of the data relay (i.e. registered host) in all 
cases. The data relay only relays data traffic to one way (to the 
registered host), right?


> 3.4.  Candidate Gathering

> Gathering of candidates MAY also be performed like specified in

like -> as

> 3.7.  Connectivity Check Pacing Negotiation

> the check pacing negotiation -> the connectivity check pacing negotiation

> 3.8.  Connectivity Checks

> [RFC5770] but instead of STUN packets, the connectivity checks are

..., but instead of STUN packets,,,

> checklist and start check transactions every Ta milliseconds as long

..start *to* check..

> The UPDATE packets that acknowledge a
> connectivity check requests MUST be sent from the same address that
> received the check and to the same address where the check was
> received from.

it would be easier to read this in singular form rather than plural:

An/Any UPDATE packet that acknowledges a connectivity check request MUST 
originate from the same address that
was used to receive the check and destined to the same address where the 
check was

received from.

(please note that I changed the wording a bit)

> The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS
> parameter with the port, protocol, and IP address of the address
> where the connectivity check request was received from.

same here:

An/Any acknowledgment UPDATE packet MUST...

> If the controlling host
> does not have any data to send, it SHOULD send an ICMP echo request

ICMPv6 inside the tunnel - right?

> using the nominated pair to signal to the controlled host that it can

... in order to signal ...

> stop checks and

Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

[Miika Komu]

Hi,

On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:

Hi,

I would like to start a WGLC on the following draft. This WGLC will end
on February 12th:

https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

Please, send your comments to this list.


in general, the draft should have a short intro to the NAT traversal 
procedure and re-introduce some terms even though it all is specified in 
RFC5770. This would make the draft a bit easier to read. I have also 
some other nits which I'll send a bit later.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Re: [Hipsec] Call for comments: Section with changes from 5201 to 5201bis

[Miika Komu]

Hi,

On 02/05/2015 09:33 AM, Gonzalo Camarillo wrote:

Folks,

during AUTH48, Tom has edited Section 10 of the 5201bis draft, which you
can find under the following link:

http://www.rfc-editor.org/authors/rfc7401.txt

Before publishing it, we would like to start a one-week call for
comments on Section 10. Please, let us know if you think we should
remove it from the document before publishing it or, on the other hand,
you think it could be useful for implementers who are familiar with 5201
and intend to implement 5201bis and thus we should keep it.


definitely keep it, I think it's very useful.

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

Re: [Hipsec] proposed changes to RFC5206-bis

[Miika Komu]

Hi Tom and Rene,

On 12/16/2014 05:18 PM, Tom Henderson wrote:

Thanks Rene for your comments; responses inline below.

On 12/15/2014 02:19 AM, Rene Hummen wrote:

Hi Tom, hi all,

please find my feedback in-line.

On 12 Dec 2014, at 02:09, Tom Henderson t...@tomh.org wrote:

Hi all, I recently published the version -07 draft of RFC5206-bis
(mobility support in HIP).  This was merely a refresh of -06; I'd
like to now start moving through and closing the remaining open
issues so we can get the document into shape for WGLC.

I made a pass through the document and plan to publish the
following (IMO) minor changes in version -08 next week, if there
are no objections.  Separately, I will start threads on remaining
open issues that require some discussion on the list.

Section 3.2  Protocol Overview -- The
draft states:

However, some implementations may want to experiment with sending
LOCATOR_SET parameters also on other packets, such as R1, I2, and
NOTIFY.

I propose to delete this sentence since we are no longer
experimental;


+1

I would actually propose to completely remove all mentioning of the
LOCATOR_SET parameter from any message type but UPDATE within the
context of this document in order to simplify host mobility to a
single procedure (UPDATE with LOCATOR_SET). If, e.g., multi-homing,
prefers the LOCATOR_SET parameter in other messages, a separate
document can specify this message flow.


I hadn't considered this, but it would be in keeping with the
mobility/multihoming scope split that we have already agreed to do.

I'll look into migrating the use of additional messages from this draft
to the multihoming draft if there are no other comments.


I would suggest to move complexity to the multihoming draft in order to 
keep the mobility extensions simple enough to be implemented e.g. for 
sensors.





later in the document (section 5.3), it states that:

A host SHOULD be prepared to receive a LOCATOR_SET parameter in
the following HIP packets: R1, I2, UPDATE, and NOTIFY.

and it leaves open to the implementation (Section 5.2) when to send
such a packet.   More on this later.


See comment above.


(also) Section 3.2: -- The draft states:

The scenarios below at times describe addresses as being in either
an ACTIVE, VERIFIED, or DEPRECATED state.

'VERIFIED' is a typo; it should be ‘UNVERIFIED'


+1


+1


3.2.1  Mobility with a Single SA Pair (No Rekeying)
--- The draft
states:

This first example considers the case in which the mobile host has
only one interface, IP address, a single pair of SAs (one inbound,
one outbound), and no rekeying

I propose to clarify 'IP address' as rather 'one IP address in use
within the HIP session', since it is seldom the case now that hosts
have one IP address system-wide, and what is really intended here
is to talk about the case for which there is only one IP address in
use.


+1


+1


3.2.3. Using LOCATOR_SETs across Addressing Realms
-- I propose to
delete this section for now; we have an open issue
(http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define
cross-family handovers, and I'd like to later propose different
text based on the work published in Secure and Efficient IPv4/IPv6
Handovers Using Host-based Identifier-Locator Split by Varjonen et
al.


Why don’t you simply replace this section with your text in an
upcoming revision? I don’t see the benefit in removing this section
right now without a proper replacement.


Partly because I hadn't come up with that replacement text yet, or
concluded that we should keep it in this draft.

I think the use case in the current draft is not very well defined (one
host has only a IPv6 locator, while the other host has only an IPv4
locator, and some middlebox manages the translation), so I would propose
to delete this case.  If so, the question is whether to try to add
something back about mobility across addressing realms in this draft.

Another possibility would be to move this topic over to the multihoming
draft, since it involves coordination across locator sets.  Any
objection if we descope it from this draft and make an cross-family
handover a use case in the multihoming draft?


I suggest to move to the multihoming draft (as I reasoned earlier).




4.3  UPDATE Packet with Included LOCATOR_SET
 There is a sentence
that says:

The sending of multiple LOCATOR_SET and/or ESP_INFO parameters is
for further study; receivers may wish to experiment with supporting
such a possibility.

I propose to delete this since supporting it is more complicated
and I am not sure of the use case.


+1

What about mandating a _single_ LOCATOR_SET parameter per HIP
packet?


I'd agree with that proposal.


+1


5.1. Locator Data Structure and Status
-- The draft states:

In a typical implementation, each 

Re: [Hipsec] RFC5201-bis and RFC5202-bis status

[Miika Komu]

Hi,

On 09/16/2014 08:20 AM, Tom Henderson wrote:

On 09/15/2014 04:37 AM, Gonzalo Camarillo wrote:

Hi Tom (Henderson),

Jari, Brian, and Ted still have discusses on this document. Could you
please summarize for each of them the status of this draft with respect
to their particular comments?

Thanks,

Gonzalo




Gonzalo, the most recent status on this draft was posted to the HIP list
in this message:

http://www.ietf.org/mail-archive/web/hipsec/current/msg03942.html

Since then, it seems that Jari and Brian have cleared their discusses.
  I believe that the IANA issues have been mostly resolved (Ted's
discuss).  Ted's discuss was against version -14 of the draft, while we
are at version -17 now.  There is a lingering comment that I haven't
picked up from Barry (item 5 in the above email) that pertains to IANA
text; I plan to publish those in version -18.

I could probably put out a version -18 shortly that may resolve all of
the open issues, but it just requires that I generate a new Appendix C
example packet.  I'll try to get to that in the next day or two.


I wrote a checksum generator, and I have independently verified that the 
checksums in RFC5201-bis are correct.


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