To: <hipsec@ietf.org>
References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com>
 <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <576BF60B.7030402@ericsson.com>
Date: Thu, 23 Jun 2016 17:45:31 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <56CB299E.5030704@ericsson.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="------------ms090601050602010005050501"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/1759pUO8RjXa4WEOv_7ZffG1DiY>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
Precedence: list

--------------ms090601050602010005050501
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

FYI,

my original concerns are now addressed in the 12 version of the draft.=20
Regarding to my last question on OSPI and ISPI, I think it is better to=20
keep things as they are (i.e. it is not mandatory for the Initiator to=20
even have a HIP relay). I discussed the topic with Ari and this follows=20
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 comment=
s
> about the protocol.
>
> On 02/16/2016 04:01 PM, Ari Ker=E4nen 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=
=2E
>> 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 mor=
e
> 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 t=
o
> 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 vi=
a
>  > 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 MUS=
T
> originate from the same address that
> was used to receive the check and destined to the same address where th=
e
> 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 ca=
n
>
> ... in order to signal ...
>
>  > stop checks and start using the nominated pair.  When the controlled=

>  > host receives the first ESP packet, it MUST select that pair for use=

>  > and send back an ESP packet to acknowledge a working candidate pair.=

>  > If the controlled host does not have any data to send, it SHOULD sen=
d
>  > an ICMP echo request.
>
> ICMPv6 inside the tunnel?
>
>  > If the connectivity checks failed the hosts SHOULD notify each other=

>  > about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message
>  > Type [RFC5770].
>
> ... failed, the hosts SHOULD ...
>
> It would also worthwhile to explain how the connectivity end in the cas=
e
> of success, maybe through an example.
>
>  > 3.9.  NAT Keepalives
>
>  > To keep the NAT bindings towards the HIP relay server and the HIP
>  > data relay alive, if a registered host has not sent any data or
>  > control messages to the relay for 15 seconds, it MUST send a HIP
>  > NOTIFY packet to the relay.
>
> When a registered host has not sent any data or control messages to the=

> relay for 15 seconds,
> it MUST send a HIP NOTIFY packet to the relay in order to keep the NAT
> bindings towards the HIP relay server and the HIP
> data relay alive.
>
>  > Likewise, if the host has not sent any
>  > data to a host it has security association and has run connectivity
>
> ... to a *peer* host ...
> ... and with which it has run ...
>
>
>  > checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo=

>  > request using the same locators as the security association is using=
=2E
>
> ICMPv6 inside the tunnel, right?
>
> ... security association is based on.
>
>  > 3.10.  Handling Conflicting SPI Values
>
>  > Since the HIP data relay determines from the SPI value to which peer=

>  > an ESP packet should be forwarded, the outbound SPI values need to b=
e
>  > unique for each relayed address registration.  Thus, if a registered=

>  > host detects that a peer would use an SPI value that is already used=

>  > with another peer via the relay, it MUST NOT select the relayed
>  > address for use.
>
> This is a bit confusing, do you mean inbound SPI values? Or from which
> viewpoint is this written?
>
>  > However, a host with many peers MAY decrease the odds of a conflict
>  > by registering more than one relayed address using different local
>  > addresses.
>
> local addresses? Do you mean in the case the host is multihomed? Or jus=
t
> by using different SPI values?
>
>  > 4.1.  RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
>
>  > This document specifies only use of UDP relaying and...
>
> ... the use of ...
>
>  > 4.2.  PEER_PERMISSION Parameter
>
>  > The parameter is used for setting up and refreshing forwarding rules=

>  > and permissions at the data relay for data packets.
>
> ... and the permission for data packets at the data relay.
>
>  > OSPI      the outbound SPI value the registered host is using for
>  >           the peer with the Address and Port
>  > ISPI      the inbound SPI value the registered host is using for
>  >           the peer with the Address and Port
>
> What happens if both of the end-host have their own data relays? Then I=

> think the OSPI could be zero.
>
> Why do you need to open both directions explicitly? I think the
> registered host should be allowed to send through the relay after
> successfuly data relay registration. So just opening the inbound
> direction should be sufficient and OSPI could be removed?
>
>  > 4.3.  HIP Connectivity Check Packets
>
> Why is the priority included separately in a new parameter since it was=

> already exhanged in the locator?
>
>  > 5.  Security Considerations
>
> I didn't find the described issue from RFC5770, but I would add that
> you're talking about non-HIP aware firewalls. Also, the relay listens a=
t
> a fixed port for registered clients, but it can decide about the port
> facing the peer host.
>
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>


--------------ms090601050602010005050501
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP
BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy
MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x
EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz
b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD
tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp
0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v
lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL
UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC
AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz
b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo
dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1
c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R
BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB
ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh
LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg
6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV
HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6
CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL
aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD
FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP
1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u
6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0
6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT
nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb
WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF
pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA
b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU
MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw
HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF
Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y
QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8
GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME
2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq
5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI
cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF
nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx
BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB
tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp
YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh
c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA
MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw
b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0
dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV
HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7
qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU
GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII
SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa
gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy
DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2
ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7
QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE
GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh
+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz
9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID
FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg
SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjIzMTQ0NTMx
WjAvBgkqhkiG9w0BCQQxIgQg/ntOKL1yVeHV++rfepROFiaui9AyAX5aqQ9C5qVgb6QwXQYJ
KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g
TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ
oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1
YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME
ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQB8x4F1FUdV
m3gDGNXZJfpqhNcHWghD6+o5bIuEj9GEhR0siPI2NjlHDcOIyMypJ5SggD1abf6a4HJ3uEAp
IOViY7g/umC1cG/XT6ciRHWXrYDJjmA+0Dc4juoJwmdCgZ1FwZJu9KfAPHYonh5/bOxrbwJh
3FD1N8LLdDCmXdeNcainuEerqwtJ7lFHjh0Ihx/E33HL+0JoHdEgyIRKuv1WrSNy7hLUBGm0
sLoqBlfi/cBNcU/pR48uadyReFLwz4De6Fp6yPON6xKoMe4HLTUYPUU8orO9247dXtyOBhSc
F/eQkKNg0z6li0XLLaIRwh0cpcDPBhvS0Ld+bIFaavjsAAAAAAAA
--------------ms090601050602010005050501--