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
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
