Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
Ben,
I will wait for your response on reading -18.
Passover is this week and I am swamped. I have one more DRIP draft to
push out before the ASTM virtual meeting later this week.
Perhaps Monday during the middle days I can read all your responses and
work up the -19 ver.
Bob
On 4/5/20 10:01 PM, Benjamin Kaduk wrote:
Hi Bob,
Sorry this dropped off my radar for so long -- I got really swamped.
Just a few notes inline, as I'll focus on reading the -18.
On Mon, Mar 09, 2020 at 04:00:33PM -0400, Robert Moskowitz wrote:
On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-dex-13: 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-dex/
--
DISCUSS:
--
This is a placeholder discuss, intended to illustrate several key
omissions from the current document and as an indication that it is not
yet ready for full IESG Evaluation. In that vein, I will defer the
evaluation shortly, to attempt to short-circuit the current round of
evaluation while the draft improves. In particular, this is not
intended to be a complete review of the document.
The FOLD scheme for compressing full host identities into ORCHIDs/HITs
is pretty problematic. The current text acknowledges that collisions
are possible and attempts to justify the scheme by pointing out that no
collision-free scheme is possible absent a cryptographic hash, which is
an appeal to authority ("we can't use a cryptographic hash on
constrained systems") that does not attempt to answer the question of
whether it is actually reasonable to use a mechanism that allows
collisions for this purpose (vs. just not being able to do anything).
Additionally, there is not any discussion of second-preimage resistance,
which is the more important property here, in terms of an attacker being
able to construct a collision with an existing HIT of an honest node.
In my humble opinion, second-preimage attack defense will be the same as
any attack against the HI -> HIT mapping function.
Fair enough. We should still use the words "second-preimage attack" in
some fashion, though, I think. (Maybe I will have thoughts about where as
I review the -18.)
The only place HITs are used in HIP unauthenticated is in the initial I1
- I2 part of the exchange. By the R2, everything is authenticated. All
other HIP messages containing HITs are authenticated.
So the attack is slipping in a HI-HIT mapping that is malicious. Per
Roman's comments, I will be adding to the I2 and R2 processing to
validate this mapping.
HIP has always had to handle probabilistic collisions. DEX now requires
checking for collisions as critical (via ACLs or other mechanisms). I
will see to adding text.
Operationally, the challenge is in those low level sensors that have no
way to have an ACL set up for the servers/gateways that they are
connected to. But this is true even for BEX. So inclusion of the
password authentication is part of the critical behavior is ACL or
(I think I maybe hadn't made it to the password authentication part when I
stopped reading the -13.)
similar HI-HIT mappings are not possible (sensors with no out-of-band
update mechanism). We are always twisting ourselves in the
chicken-and-egg problem with these devices.
In a related vein, Section 3.2.1 claims that the above concerns can be
remediated by deployment of a collision detection scheme, "achieved here
through either an ACL or some other lookup process". This process is
vital to the security of the system as a whole, and it would be
irresponsible to publish this document without a precise specification
of what properties are needed in order to perform this process, as well
as a worked example that can be used absent other considerations.
I will be adding this per Roman's comments. Most will be in the I2 and
R2 processing.
Given that the applicability statement ("in communicating with such
constrained devices") implies that there is intent to have full-featured
nodes that implement both HIP DEX and HIP BEX, I think we need
significantly more discussion of how such nodes avoid using DEX in
situations where it was not appropriate. That is, how is it known that
the peer should be using DEX vs. BEX? Yes, the HIT includes an
indication of whether the identity is for use with DEX vs. BEX, but that
does not seem like quite the relevant property. Do we envision
scenarios where a node is positioned somewhat like a gateway,
Re: [Hipsec] Benjamin Kaduk's Discuss on draft-ietf-hip-dex-13: (with DISCUSS and COMMENT)
Hi Bob,
Sorry this dropped off my radar for so long -- I got really swamped.
Just a few notes inline, as I'll focus on reading the -18.
On Mon, Mar 09, 2020 at 04:00:33PM -0400, Robert Moskowitz wrote:
>
>
> On 3/4/20 12:44 PM, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-hip-dex-13: 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-dex/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > This is a placeholder discuss, intended to illustrate several key
> > omissions from the current document and as an indication that it is not
> > yet ready for full IESG Evaluation. In that vein, I will defer the
> > evaluation shortly, to attempt to short-circuit the current round of
> > evaluation while the draft improves. In particular, this is not
> > intended to be a complete review of the document.
> >
> > The FOLD scheme for compressing full host identities into ORCHIDs/HITs
> > is pretty problematic. The current text acknowledges that collisions
> > are possible and attempts to justify the scheme by pointing out that no
> > collision-free scheme is possible absent a cryptographic hash, which is
> > an appeal to authority ("we can't use a cryptographic hash on
> > constrained systems") that does not attempt to answer the question of
> > whether it is actually reasonable to use a mechanism that allows
> > collisions for this purpose (vs. just not being able to do anything).
> > Additionally, there is not any discussion of second-preimage resistance,
> > which is the more important property here, in terms of an attacker being
> > able to construct a collision with an existing HIT of an honest node.
>
> In my humble opinion, second-preimage attack defense will be the same as
> any attack against the HI -> HIT mapping function.
Fair enough. We should still use the words "second-preimage attack" in
some fashion, though, I think. (Maybe I will have thoughts about where as
I review the -18.)
> The only place HITs are used in HIP unauthenticated is in the initial I1
> - I2 part of the exchange. By the R2, everything is authenticated. All
> other HIP messages containing HITs are authenticated.
>
> So the attack is slipping in a HI-HIT mapping that is malicious. Per
> Roman's comments, I will be adding to the I2 and R2 processing to
> validate this mapping.
>
> HIP has always had to handle probabilistic collisions. DEX now requires
> checking for collisions as critical (via ACLs or other mechanisms). I
> will see to adding text.
>
> Operationally, the challenge is in those low level sensors that have no
> way to have an ACL set up for the servers/gateways that they are
> connected to. But this is true even for BEX. So inclusion of the
> password authentication is part of the critical behavior is ACL or
(I think I maybe hadn't made it to the password authentication part when I
stopped reading the -13.)
> similar HI-HIT mappings are not possible (sensors with no out-of-band
> update mechanism). We are always twisting ourselves in the
> chicken-and-egg problem with these devices.
>
> > In a related vein, Section 3.2.1 claims that the above concerns can be
> > remediated by deployment of a collision detection scheme, "achieved here
> > through either an ACL or some other lookup process". This process is
> > vital to the security of the system as a whole, and it would be
> > irresponsible to publish this document without a precise specification
> > of what properties are needed in order to perform this process, as well
> > as a worked example that can be used absent other considerations.
>
> I will be adding this per Roman's comments. Most will be in the I2 and
> R2 processing.
>
>
> > Given that the applicability statement ("in communicating with such
> > constrained devices") implies that there is intent to have full-featured
> > nodes that implement both HIP DEX and HIP BEX, I think we need
> > significantly more discussion of how such nodes avoid using DEX in
> > situations where it was not appropriate. That is, how is it known that
> > the peer should be using DEX vs. BEX? Yes, the HIT includes an
> > indication of whether the identity is for use with DEX vs. BEX, but that
> > does not seem like quite the relevant property. Do we envision
> > scenarios where a node is positioned somewhat like a gateway, using DEX
> > on one interface and BEX to the
Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)
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
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)
Hi Magnus, pe, 2020-04-03 kello 09:49 +, Magnus Westerlund kirjoitti: > Hi, > > See below. > > On Fri, 2020-04-03 at 06:41 +, 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] [RFC8201]. > - Reliance on IP fragmentation is unlikely to be a viable strategy > through NATs > so if ICMP MTU discovery is not working MTU realted path black holes > may occur. > - A mitigation is to constrain the MTU, especially for virtual > interfaces to > expected to be safe MTU values, e.g. 1400 bytes for underlying > interfaces that > support 1500 bytes MTU. > - (to include something realted to below discussion consider this > bullet also, > assumes that PLP MTUD actually can be implemented in HIP relay rather > simply): > Implement PLPMTUD [draft-ietf-tsvwg-datagram-plpmtud] in HIP to find > a working > path MTU without unnecessary constraining that size. > > Has anyone looked at implementing > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ > (document is > in IESG evaluation) style path MTU discovery between the HIP client > and the >
