Re: [Hipsec] Implementation questions from students

[Jeff Ahrenholz]

Hi Andrei et al.,

Some inline comments below...

> We had some questions about the HIP project that you could perhaps forward to 
> the correct person:
> 1. In the function build_tlv_hmac() in src/protocol/hip_output.c, there is 
> the following bit of code:
> /* get lower 160-bits of HMAC computation */
> memcpy( hmac->hmac,
> _md[hmac_md_len - sizeof(hmac->hmac)],
> sizeof(hmac->hmac));

We currently use the HMAC() function writing directly into the TLV buffer. 
We're not truncating the output hash when using AES-256.

> Also, per RFC 7401 (HIPv2), "The size of the HMAC is the natural size of 
> the hash computation output depending on the used hash function". Thus 
> there does not seem to be a need to truncate this value to 160 bits?
>  At least one implementation (https://www.cryptosys.net/manapi/api_kmac.html)
> of the KMAC function (that we have added as an option to HMAC) also states
> that the output of the KMAC function cannot be truncated when used as a 
> message authentication code.

This likely stems from the original RFC 5201 / RFC 5202 required algorithms. 
You're correct, with AES-256 and others you do not need to truncate the output 
hash. Although that is allowed by old RFCs such as RFC 2104.

> There is a fallback in hi_to_hit() which silently uses SHA256 as
> the hashing algorithm for creating a HIT from a HI if the HIT suite 
> is set to an invalid value, which enables the verification to succeed 
...
> We have worked around this issue by first ignoring all parameters 
> other than the HIT_SUITE_LIST (thus ensuring that the HIT suite 
> variable is set before any other parameters are parsed), then continuing
> with parsing the signature-related parameters and finally the others. 
> Is this an acceptable solution to this problem? Those silent fallbacks 
> seem to cause more problems that they solve, maybe they should be removed
> or at least emit a warning when triggered?

Yes, I think you should remove the silent fallback.

You should be able to use the OGA ID field of the HIT in order to validate the 
HIT.
From RFC 7401 section 3.1:

"  One of these
   measures allows different hash functions for creating a HIT.  HIT
   Suites group the sets of algorithms that are required to generate and
   use a particular HIT.  The Suites are encoded in HIT Suite IDs.
   These HIT Suite IDs are transmitted in the ORCHID Generation
   Algorithm (OGA) field in the ORCHID.  With the HIT Suite ID in the
   OGA ID field, a host can tell, from another host's HIT, whether it
   supports the necessary hash and signature algorithms to establish a
   HIP association with that host."

The HIT_SUITE_LIST TLV is used to list the supported HIT SUITE IDs.

See RFC 7401 section 5.2.10 around this text:

"   The ID field in the HIT_SUITE_LIST is defined as an eight-bit field,
   as opposed to the four-bit HIT Suite ID and OGA ID field in the
   ORCHID."

I don't think you should parse the HIT_SUITE_LIST when validating the HIT.

> Seeing as this function will then sometimes calculate a HMAC and other
> times a KMAC, should it be renamed to build_tlv_mac()? Or will it be
> less intrusive to others (that might be used to the name) to not
> change it even though the name might be misleading? 

The new name build_tlv_mac() sounds good.

regards,
-Jeff


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

Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt

[Jeff Ahrenholz]

Bob,
Brief review below...

> I have updated the hip-fast-mobility draft.
>
> I welcome review.
>
> It will be used in an upcoming DRIP N-RID secure transport draft that will 
> also include secure C2 transport.

General comments:

- Overall I think the draft looks good, it is a short read and quite 
straightforward.
  The TLDR: 
  1) include VIA_RVS more often (always in R1/I2), so peers always know how to 
reach you,
  2) don't wait for complete address verification for using an address
  3) piggyback upper layer data when possible

- What about IPv4? There is no mention of it. And no extension header field 
like IPv6.

- Did you consider the Credit-Based Authorization technique in section 3.3.2 of 
RFC 8046? You could maybe mention in this draft that it could optionally be 
used here? (Plays well / same concept as the send-before-verified.)
  
Section 5.4.1
"the datagram is sent separately after receipt of the HIP UPDATE from Host B."

This implies buffering packets after you've sent an UPDATE but waiting for 
UPDATE-ACK; we almost need a new association state "moving" because how long 
will you wait and buffer packets? What if the UPDATE-ACK is lost or not sent -- 
need to tear down?

In practice, sometimes we're seeing dropped packets during mobility (depends on 
how quickly host can acquire a new address after losing the old address). Also 
we recently removed the initial-packet-embargo from our implementation 
(buffering packets while waiting for BEX to complete) as the complexity wasn't 
warranted (e.g. upper layers typically retransmit; packets likely to be stale.)

Consider also switching interfaces, which may have differing MTUs (e.g. 
cellular/Ethernet failover.)

Section 8 Security Considerations:

Adding the VIA_RVS parameter to more packets -- any security considerations, 
since this is typically outside the signature? RFC 8004 indicates "The main 
goal of using the VIA_RVS parameter is to allow operators to diagnose possible 
issues" but here you're suggesting to use the address during shotgunning.


Below are some editorial nits:

Section 5.1

consider replacing:
"An implementation may be able to adjust the
   transport window size downward so that the higher layer could still
   fill it and the whole piece then still fit within the MTU."
with:
"An implementation may be able to adjust the
   transport window size downward so that the higher layer could
   fit its data plus the UPDATE payload within the MTU."
   
5.2
s/others RVS/other's RVS/
5.3 and 5.4
s/of new address/of a new address/

5.5.1 and 5.5.2
s/wait from HIP UPDATE/wait for HIP UPDATE/

7. IANA Considerations
there is no PAYLOAD_MIC used here

-Jeff

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

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

[Jeff Ahrenholz]

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

Re: [Hipsec] Help needed - text to octet for HIP-DEX

[Jeff Ahrenholz]

Bob et al.,

>There are two strings used in the KEYMAT process i HIP-DEX:
>
>CKDF-Extract
>and
>CKDF-Expand
>
>The draft says that they are "an octet string".
>
>Thing is that depending on which google found tool, I get different text 
>to octet values!
>
>So to those implementors out there:
>
>What is the proper octet strings for the above two text strings?

>From an implementation perspective, here are some Python3 snippets:
(ord() returns the Unicode codepoint for a character, 
 oct() returns the octal representation, and
 hex() returns the hexadecimal representation)

input="CKDF-Extract"

# the values Roman suggested, shown as ASCII decimal values:
>>> list(map(lambda i: ord(i), input))
[67, 75, 68, 70, 45, 69, 120, 116, 114, 97, 99, 116]

# the tool you were using showed octal values:
>>> list(map(lambda i: oct(ord(i)), input))
['0o103', '0o113', '0o104', '0o106', '0o55', '0o105', '0o170', '0o164', 
'0o162', '0o141', '0o143', '0o164']

# hex representation of the above:
>>> list(map(lambda i: hex(ord(i)), input))
['0x43', '0x4b', '0x44', '0x46', '0x2d', '0x45', '0x78', '0x74', '0x72', 
'0x61', '0x63', '0x74']

In the appendix of e.g. RFC 5201, we show hexadecimal values... in this case 
you could put:
input text: "CKDF-Extract"
hex string: 0x434b44462d45787472616374

input text: "CKDF-Expand"
hex string: 0x434b44462d457870616e64

So the hex looks good to me, but you could use either of the other 
representations as long as we explicitly state what they are.

-Jeff

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

Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)

[Jeff Ahrenholz]

>  Here is the text I put together for revising sec 5.4 (see below).

It seems good to me.

-Jeff
 

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

Re: [Hipsec] Suresh Krishnan's Discuss on draft-ietf-hip-dex-13: (with DISCUSS)

[Jeff Ahrenholz]

>
> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5
>
> And nothing there that looks right. 
> 
> So what is done in HIP BEX implementations?  Both v1 and v2?

For our HIPv1 implementation:
IPv4 packets - we send ICMPv4-in-UDP with type 12 "parameter problem" code 0 
"pointer indicates the error" and point to the first bytes of UDP payload. 
(https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-12)

IPv6 packets - we send ICMPv6-in-UDP with type 4 "parameter problem" code 0 
"erroneous header field encountered" and point to the first bytes of UDP 
payload. 

Normally this would be if the SPI is unknown (e.g. one side forcefully reboots 
while the other continues to send it ESP-in-UDP data.) The pointer includes the 
first 8 bytes of the UDP payload so that the SPI is included in the ICMP 
message.

For IPv6 you could consider the "erroneous header field" to be the invalid SPI 
number, which is the bytes we point to.

-Jeff

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

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

[Jeff Ahrenholz]

>> 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.
>
>In 6.3:
>
>IKM   Input keying material
>the Diffie-Hellman derived key, concatenated with the
>  random I_NONCE value for the Master Key SA
>the Diffie-Hellman derived key, concatenated with the
>  random values of the ENCRYPTED_KEY parameters in
>  the same order as the HITs with sort(HIT-I | HIT-R)
>  for the Pair-wise Key SA

Is this a new table row, or maybe something happened to the output?

It looks good.

In the dex-12 html/text versions I'm seeing the following text, which does not 
list IKM or info inputs for CKDF-Extract:


   The CKDF-Extract function is the following operation:

 CKDF-Extract(I, IKM, info) -> PRK

 Inputs:
   I Random #I, provided by the Responder, from the PUZZLE
 parameter

   The CKDF-Expand function is the following operation:




Moskowitz, et al.Expires August 12, 2020   [Page 32]


Internet-Draft   HIP Diet EXchange (DEX)   February 2020


 CKDF-Expand(PRK, info, L) -> OKM

 Inputs:
   PRK   a pseudorandom key of at least RHASH_len/8 octets
 (either the output from the extract step or the
 concatenation of the random values of the
 ENCRYPTED_KEY parameters in the same order as the
 HITs with sort(HIT-I | HIT-R) in case of no extract)
   info  sort(HIT-I | HIT-R) | "CKDF-Expand"
 where "CKDF-Expand" is an octet string
   L length of output keying material in octets
 (<= 255*RHASH_len/8)   

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

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

[Jeff Ahrenholz]

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

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.

-Jeff


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

Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-hhit-registries-00.txt

[Jeff Ahrenholz]

> And the new cipher choice is Keyak.  For now.  How do we get the ESP transform
> number assigned?  What docs do we need for that?

Probably needs a short RFC, similar to this one?  
https://tools.ietf.org/html/rfc4543

And this:  https://www.iana.org/protocols/apply

-Jeff


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

Re: [Hipsec] IESG review of NAT traversal draft and encrypted parameters

[Jeff Ahrenholz]

Miika,

>I don't think we need XORring with HIP because we have more powerful 
>mechanisms in HIP. So, I am going to add some text that mandates that 
>the LOCATOR parameter must be encapsulated inside ENCRYPTED parameter 
>when ICE-HIP-UDP will be used. The tradeoff here is that we favor 
>end-host privacy at the cost middlebox transparency.

Seems like a good use of ENCRYPTED to me.

I'm not sure what kind of middlebox would need to know all of the address 
candidates. Maybe some extra signaling could be devised when that needs to 
happen (like a HIP-aware middlebox where addresses can be communicated via HIP.)

Thanks for continuing the work on this!

-Jeff

___
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

[Jeff Ahrenholz]

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"  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] WGLC: draft-ietf-hip-native-nat-traversal-15

[Jeff Ahrenholz]

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

thanks,
-Jeff


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

Re: [Hipsec] Using Next Header with IPv6

[Jeff Ahrenholz]

Hi Bob,
Adding to Tom’s comments...

>> We provided in 7401 a Next Header field as all good IPv6 payloads are
>> suppose to do.  But we really have not used it in front of 'real' IPv6
>> payloads like ESP, TCP, UDP, or IPnIP.  Or have we and I have just
>> missed it?
>
>The HICCUPS RFC describes a use of it.
>https://tools.ietf.org/html/rfc6078

Yes, we haven’t really been using the Next Header field for payloads.

>> I am not a person that has dealt with the insides of the OS(s) to know
>> how this would be done or if it is really practical.
>
>The data plane for HIP-supported sessions can be implemented in userspace
>or kernel (reusing kernel IPsec handling). If purely userspace (all packets
>are shunted to userspace) it seems like it would not be terribly difficult
>to do.  If kernel space handling such as Linux XFRM, I'm guessing that a
>stack modification would be needed.

We’re using a userspace implementation plus UDP encapsulation.

So one UDP socket receives the port 10500 traffic. Both HIP control packets 
(having SPI=0) and ESP packets are received and demuxed on this socket. So it 
would be fairly straightforward to pick off an UPDATE and then process the ESP 
data that follows it.

If we were not using UDP encaps then yes it seems you’d have to write a new 
frame back to the stack.

>> 
>> Oh, and what is the length of the basic HIP UPDATE in 5206-bis?  I can
>> do my best calculation in a bit, but if someone has it...
>
>HIP header 40 bytes
>ESP_INFO 16 bytes
>LOCATOR_SET (minimal) ~32 bytes
>SEQ parameter 8 bytes
>
>so on the order of 96 bytes; more if more than one locator involved

Here is what we have for an IPv4 re-address event over UDP. Attached is a pcap 
file (you can open in Wireshark).

The three UPDATE packets are 302, 286, 262 bytes in length. They look like this:
UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC, HIP_SIGNATURE)
UPDATE(ESP_INFO, SEQ, ACK, HMAC, HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED)
UPDATE(ESP_INFO, ACK, HMAC, HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED)

-Jeff




hip-over-udp-readdress-20160920.pcapng
Description: hip-over-udp-readdress-20160920.pcapng
___
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

[Jeff Ahrenholz]

On 6/30/16, 9:06 AM, "Miika Komu"  wrote:
>> Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way 
>> comms between peers.
>> For example, when performing a registration procedure with a relay server.
>
> The direct path could be, of course, used for exchange HIP messages 
> directly (including hiccups v2). Does this make sense?

yes, makes sense

> If not, what should happen when both ESP_TRANSFORM and ICE-HIP-UDP are 
> both negotiated? Or should we just be proactive and state that upon 
> receiving R1, the Initiator MUST NOT include ICE-HIP-UDP if it is not 
> going to employ any ESP_TRANSFORM.

This proposed sentence seems like a good revision.

> Connectivity tests implement the return routability checks. Currently, 
> the NAT mobility triggering mechanism mimics the tree-way procedure in here:
>
> https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12#section-3.2.1
>
> I thought that would nice for implementers but strictly speaking steps 
> 5-6 could skipped since the connectivity checks actually implement the 
> return routability checks.
>
> I can change this if you agree?

Yes, I agree they can be skipped. 
The connectivity checks are more UPDATE packets, and fewer update round-trips 
seems like faster mobility handover.

-Jeff

___
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

[Jeff Ahrenholz]

Miika,

> On 6/30/16, 1:12 AM, "Miika Komu"  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.

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

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.

Not sure what happens if you send the R2 without the relayed address -- proper 
state not created on the Initiator?

-Jeff

___
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

[Jeff Ahrenholz]

Hi Miika,
First of all, nice work with all of your changes! 
This is a big draft but seems much clearer without the RFC 5770 delta.

Here’s some further comments on your questions...

>   * What should do with compatibility with RFC 6078 (HICCUPS)

I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wait until 
if/when 6078 is updated for HIPv2.)

>* Connectivity tests should be skipped unless ESP_TRANSFORM is
> negotiated?

Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way comms 
between peers.
For example, when performing a registration procedure with a relay server.

>   * Steps 5-6 could be skipped in the handoff sequence? See fig. 6.

If steps 5-6 are skipped, then we would have no SEQ in step 3?
And the subsequent connectivity checks would suffice for these steps?

Below are a few editorial nits...

-Jeff

page 2
s/checks keepalives, and data relaying./check keepalives and data relaying./g

page 7
s/IPsec [RFC3948] Finally/IPsec [RFC3948]. Finally/

page 15
s/NATs drop messages messages/NATs drop messages/

page 18
s/the the recipient/the recipient/

page 22
s/interact handover/interact with handover/

page 27
s/MUST not/MUST NOT/

___
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

[Jeff Ahrenholz]

Hi Miika,
I was reviewing this section...

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

When there is a SPI collision, it does seem that we would want a new type of 
NOTIFY to be sent.

Otherwise it seems the Initiator will be stuck in the state I2-SENT, 
retransmitting the I2 until going back to the failure state, when it can retry 
the BEX from the beginning again.

Maybe it needs to be an ICMP message (and not NOTIFY) since there is not yet an 
association between the two peers (RFC 7401 section 4.3).

-Jeff



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