Subject: RE: [Mobike] FW: external mobike-protocol-02 review (technical) (issue 42)

From: <[email-masked]>
Date: Mon, 19 Sep 2005 19:31:33 +0300

Pekka Savola wrote:
> 
> (Note: I'm not subscribed)
> 
> Jari asked me to review the MOBIKE protocol.  Beware, I'm not
> really familiar with IKE, so there are probably things I have
> wrong or have missed.

Thanks for your thorough review! (I've filed it as issue #43).

> In any case, I thought the document was in a good shape and
> written in a manner where it should be easy to get
> interoperable implementations.  It's also short -- good.  What
> troubled me a bit was a significant number of forward
> references to other places in the spec, but this is
> understandable in the interest of avoiding text duplication.
> 
> 
> meta-issues
> -----------
>    It is assumed that issues such as transport mode (updating
>    traffic selectors), PFKEY extensions, and tunnel overhead
>    reduction will be handled in separate documents.
> 
> ==> is transport mode even in the scope of the WG?  I thought 
> not, but the charter doesn't seem conclusive either way..

Well, this sentence in the draft was not intended as an opinion
either way; only as a note that regardless of whether it's in the
WG scope or not, it's certainly not within the scope of this
document :-)

> substantial
> -----------
> 
>    Note that if some of the initiator's interfaces are behind a
>    NAT (from the responder's point of view), the addresses
>    received by the responder will be incorrect.  This means the
>    procedure for changing responder addresses described in
>    Section 2.4 does not fully work when the initiator is behind
>    a NAT. [...]
> 
> ==> this is probably something that needs more air time.  What
> does "does not fully work" mean?  This also probably applies to
> the responder, though in different ways.  This may also have
> security implications (exposing internal topology), and it may
> affect address selection (if for example smaller scope
> addresses are preferable, but actually belong to different
> sites).  This probably needs a bunch of more analysis...

Yes, this is something that probably deserves a slightly longer
explanation (but I don't think we should spend too much time on
it). How about this?

1.3  MOBIKE and Network Address Translation (NAT)

   In some MOBIKE scenarios the network may contain NATs or stateful
   packet filters (for brevity, the rest of this document talks simply
   about NATs).  The NAT Traversal feature specified in [IKEv2] allows
   IKEv2 to work through NATs in many cases, and MOBIKE can leverage
   this functionality: when the addresses used for IPsec SAs are
   changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.

   Nevertheless, there are some limitations.  NATs usually introduce an
   asymmetry in the network: packets reaching the NAT from the "inside"
   are treated differently from packets coming from the "outside".  This
   asymmetry leads to restrictions on what MOBIKE can do.  To give a
   concrete example, consider a situation where both peers have only a
   single address, and the initiator is behind a NAT.  If the
   responder's address now changes, it needs to send a packet to the
   initiator using its new address.  However, if the NAT is, for
   instance, of the "restricted cone" type (see [STUN] for one
   description of different NAT types), this is not possible: the NAT
   will drop packets sent from the new address (unless the initiator has
   previously sent a packet to that address -- which it cannot do until
   it knows the address).

   For simplicity, MOBIKE does not attempt to handle all possible NAT-
   related scenarios.  Instead, MOBIKE assumes that if NATs are present,
   the initiator is the party "behind" the NAT, and does not fully
   support the case where the responder's addresses change.

   "Does not fully support" means that no special effort is made to
   support this functionality.  However, if the alternative is losing
   connectivity completely, the responder can still attempt to proceed
   with the change, and depending on, e.g., the exact type of NAT, it
   may succeed.  However, analyzing the exact circumstances when this
   will or will not work is not done in this document.

>    This specification requires the use of return routability
>    tests (under certain conditions) to limit the duration of
>    any "third party bombing" attacks by off-path (relative to
>    the victim) attackers.
> 
> ==> this is not true.  The spec only says RR _SHOULD_ be done
> before updating the SAs.  There is no "MUST" for RR (whether
> before or after), but a "MAY skip" under certain conditions.
> The normativeness requirements need to be reviewed.  

Yes, the security considerations text needs to be fixed.

> Further, the procedures for handling the payloads (sections 2.3
> and 2.4) should include a bullet point on RR tests and a
> pointer to 2.5.

Section 2.3 already has this for the responder; I'll add this
for the initiator as well..

>   When the initiator is behind a NAT, it SHOULD include these 
>   payloads in DPD messages, and compare the received ...
> 
>   When MOBIKE is in use, the host not behind a NAT SHOULD NOT 
>   use the dynamic updates specified ...
> 
> ==> How does the MOBIKE code know whether you're behind a NAT?
> Is this done automatically as part of IKEv2 NAT detection?
> Note that the spec doesn't seem to require running NAT presence
> detection so with current spec this can't be done.

Yes, this is done by IKEv2 NAT Traversal already (so saying
that it must be done would be redundant).

>    To give the initiator enough time to detect the error, the 
>    responder SHOULD use relatively long timeout intervals when, 
>    for instance, retransmitting IKEv2 requests or deciding whether 
>    to initiate dead peer detection.
> 
> ==> "relatively long timeout intervals" is pretty ambiguous.
> While this may not affect the interoperability, shouldn't we be
> a bit more precise what kind of order of magnitude we're
> talking about here?  Seconds?  Ten seconds?  30 sec?  Minutes?
> 10 minutes? Hours?

This is to some degree also a matter of local policy... but I
guess it would be useful to at least give a reasonable example.

Tero, do you have an opinion about what would a good
recommendation be? Maybe something like

   "While no specific timeout lengths are required, it is
   suggested that responders continue retransmitting IKEv2
   requests for at least five minutes before giving up."

>    The data associated with this notification is the SHA-1 
>    hash [FIPS180-2] of the following data:
> 
> ==> this spec is not algorithm-agile. (I can't find the ref
> right now where this is encouraged.)  In this case, maybe it
> doesn't need to be considering the impact (I don't take a
> stance on that) -- but this probably deserves at least brief
> discussion in the security considerations section.

This part is basically copied from IKEv2 NAT detection payloads,
which also use SHA-1 (and IKEv2 spec didn't include any
discussion about this either)....

However, here the situation might actually be slightly different,
since the security implications of NAT_DETECTION_*_IP payloads
and NO_NATS_ALLOWED are different. The simplest solution might
be just to place the IP addresses in this payload (and mandate
comparing them with the IP header)...

Any comments from other on this?

> semi-editorial
> --------------
> 
> ==> there seem to be a number of assumptions scattered
> throughout the document (e.g., relating to the responder not
> being behind a NAT) -- maybe it would be useful to put these as
> a new subsection of the Introduction?

This particular assumption is actually mentioned in the
Introduction section (and gets better treatment in the proposed
NAT text above). Were there any others you had in mind..?

> ==> I would also consider splitting out 2.3 in subsections for
> readability and more exact references.  For example,
> initiator's first steps could be 2.3.1, Responder's reply
> 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4.

Hmm... as it's currently organized, I'm not sure if splitting 
it would actually improve the readability (it might even be
confusing if the subsection suddenly changes in the middle of 
the description).

> ==> It might make sense to spell out, probably in section 1.2,
> that apparently (AFAICS) the initiator never tells the
> responder which addresses it takes to use.  It just sends
> UPDATE_SA_ADDRESSES with the updated addresses (inmplicit
> update).

It does tell the responder, by sending UPDATE_SA_ADDRESSES.
I'm not sure how it could be more explicit than this...?

(Or are you referring to the detail that the addresses are not
contained inside the IKEv2 payload, but in the IP header?)

>      HDR, SK { IDi, [CERT], [IDr], AUTH,
>                 [CP(CFG_REQUEST)]
>                 SAi2, TSi, TSr,
>                 N(MOBIKE_SUPPORTED),
>                 [N(ADDITIONAL_*_ADDRESS)+]  -->
> 
> ==> this raises a minor issue of the normativeness of this spec
> with regard to the non-MOBIKE -related IKE payloads.  The above
> exchange is just an example; some other payloads could be
> included as well, or some listed above could be omitted.  Also
> the optional/mandatory status might change.  Perhaps the
> document could give a short disclaimer about the IKE exchange
> examples.

Right... How about adding this:

   In some cases, the diagrams also show what payloads defined in
   [IKEv2] would be typically included in, for instance, the
   IKE_AUTH exchange. These payloads are shown for illustrative
   purposes only; see [IKEv2] for an authoritative description.

to section 1.3, after the first paragraph?

>    o  The initiator receives a NAT_DETECTION_DESTINATION_IP 
>       payload that does not match the previous UPDATE_SA_ADDRESSES 
>       response (see Section 2.6 for a more detailed description).
> 
> ==> In some cases, you use NAT_DETECTION_*_IP and in some
> NAT_DETECTION_DESTINATION_IP.  I guess this is intentional, 
> but I'd still review the cases carefully..

I went through all the occurrences of these terms, and it seems
they were all correct.

>    o  Determines whether it has already received a newer
>       UPDATE_SA_ADDRESSES request than this one (if the 
>       responder uses a window size greater than one, it is 
>       possible that requests are received out of order).  
>       If it has, a response message is sent, but no other 
>       action is taken.
> 
> ==> at first, it was not clear to me what "a response message"
> referred to. An unspecified response?  Probably you meant the
> normal response specified a few bullets down but this was not
> unambiguous.

Ok, I'll clarify this.

>    There is one additional issue that must be taken into account.
>    If the INFORMATIONAL request has been sent to several different
>    addresses (i.e., the destination address in the IKE_SA has been
>    updated after the request was first sent), ...
> 
> ==> s/If the/If the same/ (?)

Yes, that's right.

> ==> this is actually a good issue in more general.  Is it worth
> the effort to do so in the first place? That is, couldn't we
> just specify that the requests be sent with different cookies
> for each destination. I don't think a hash is computationally
> all that expensive.  That would simplify the spec and eliminate
> an extra roundtrip in some cases.

This would require everyone to support large "window sizes", and
based on feedback we've received from implementors, most of them
don't plan to support anything else than 1.

(MOBIKE in general would be _much_ simpler if the designers of
IKEv2 had done the reliability/windowing parts slightly 
differently...:-)

>    IKEv2 requires that if an IPsec endpoint discovers a NAT
>    between it and its correspondent, it MUST send all
>    subsequent traffic to and from port 4500.  To simplify
>    things, implementations that support both this specification
>    and NAT Traversal MUST change to port 4500 if the
>    correspondent also supports both, even if no NAT was
>    detected between them (this way, there is no need to change
>    the ports later).
> 
> ==> While this seems to be a logical place to talk about this,
> I'm troubled. The title is "NAT Prohibition".  What about
> MOBIKE implementations which don't implement NAT prohibition (I
> guess that's OK).  The above requirement is more general though
> -- not really anything to with NAT prohibition.  These kind of
> more generic requirements should be placed in a much more
> prominent place in the spec.

Hmm... yes, you're right, this should be somewhere else. 
Logically it would also belong earlier in the text; I'll
try to find a new place for it.

>    NO_NATS_ALLOWED payloads can also be included when changing
>    the addresses of IPsec SAs (see Section 2.3) and updating
>    the additional addresses (see Section 2.4).  An initiator
>    using this "NAT prohibition" feature includes a
>    NO_NATS_ALLOWED payload in all address update messages.
> 
> ==> s/includes/MUST include/ or..?

I think "includes" is correct, since it's describing a logical
necessity, not a choice (where we could discuss whether it 
should be a MAY, SHOULD or MUST).
 
> 3.1  MOBIKE_SUPPORTED Notification Payload
> 
> ==> note that the IKEv2 spec refers these as "Notify Payloads"
> (at least in some places of the spec; "Notification" is also
> mentioned though)..?

The IKEv2 spec is not very consistent in this (for instance,
Section 3.10 titled "Notify Payload" later on says "The payload
type for the Notification Payload is...").

But I'll try to make the use of "notification", "Notify Payload", 
and "payload" more consistent in the next version.

>    The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-
>    IANA(16396..40959).
> 
> ==> per http://www.ietf.org/internet-drafts/draft-narten-iana-
> considerations-rfc2434bis-02.txt,
> 
> thse types should be named TBD-BY-IANA1, ...., TBD-BY-IANAN (or
> something like that), so we know IANA has assigned a separate
> value for each and it can be easily search-n-replaced.
>
> I'd also suggest dropping the assignment range from here, and 
> giving that guidance in IANA Considerations.

OK, I'll do that... (I'll also add a table in the IANA
considerations section summarizing all the new notifications).

>   of the stack, such as properly dealing with ICMP errors
>   [ICMPAttacks]
>
> ==> some folks may argue that what ICMPattacks proposes may not
> be "proper". So, maybe find a different word for "proper", or
> use something like "as validating ICMP errors" which takes no
> stance on whether it's useful or not.

Ok.

>   [IPsecArch]
>              Kent, S. and K. Seo, "Security Architecture for the
>              Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 
>              (work in progress), March 2005.
>
> ==> this should probably be under normative refs?

Yes.

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Sep 2005 14:16:13 +0200

=> you don't answer to the question: it is not required to
run NAT presence detection.

   The simplest solution might
   be just to place the IP addresses in this payload (and mandate
   comparing them with the IP header)...

=> so I am not the one which cares about peer address protection (:-).

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Sep 2005 14:03:19 +0300 (EEST)

Inline.. (in the interest of brevity, I've removed parts which we 
agree on explicit response doesn't seem necessary).  Let's hope this 
gets past the size limitations..

>   will or will not work is not done in this document.

This is good description of some of these problems (suitable in the 
introduction as you put it), but I'm not sure if it addresses all the 
open questions.

If I understand correctly, if the initiator is behind a NAT with IP 
address 10.0.0.1, it will tell the responder in MOBIKE exchange that 
its IP address is 10.0.0.1.  At least two issues sprang to my mind:

   a) some people will be (at least slightly) concerned that MOBIKE 
will reveal the internal topology of the site.  This may or may not be 
a big issue (especially as probably the most IPsec sessions will go to 
at least semi-trusted nodes), but if we don't state it now, someone is 
going to invent a fancy MOBIKE "exploit" 5 years down the road.  A 
sentence or two in a separate paragraph in Security Considerations 
section would probably be sufficient.

   b) as the conveyed addresses are used for address selection, there 
might be issues with that.  Let's say, the responder tells it has 
addresses 20.20.20.20 and 10.0.0.2.  The initiator has 10.0.0.1, and 
possibly 30.30.30.30.  The initiator and responder are in different 
sites (a NAT between them). Now the initiator's address selection 
policy might get skewed if it'd prefer particular kind of addresses.
This may be one issue where an explicit warning might be useful.

> that it must be done would be redundant).

To a person like me who didn't know what kind of NAT detection 
exchange is done by IKEv2 (and whether that's mandatory to implement 
or mandatory to enable), this didn't spell out how MOBIKE knows 
whether it's behind a NAT or not.  If it could fit somewhere neatly, 
it would likely help a bit.

>   requests for at least five minutes before giving up."

No problem with me, though that doesn't give any help on how 
aggressive you should be to start with..

> Any comments from other on this?

As these issues have seen some debate (see the thread starting from 
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an 
example), this seems to be something that needs to be at least 
mentioned in security considerations; that may be sufficient, though 
if one can easily engineer around it without hurting security, that 
might not be a bad idea either.

But the bottom line is that if the algorithm is glued in (which may be 
OK given that you can only spoof the NAT prohibition), I think it 
needs to be said explicitly (and it might not hurt to get tentative 
early review from more folks in the sec area).

> NAT text above). Were there any others you had in mind..?

Maybe minor ones like the assumptions on what other elements need to 
be implemented (but which aren't specified here, like address 
selection), but it may be that those don't need to be mentioned up 
front.

> confusing if the subsection suddenly changes in the middle of

If others have no opinion, I'm OK either way.  It required a bit more 
work from the reader to figure out which part of the section you were 
referring to when saying "see Section 2.3" because that includes a 
number of different things.  Above would have made it shorter and 
easier to point to, but with more careful reading, the current one 
should be readable as well.

> contained inside the IKEv2 payload, but in the IP header?)

Exactly, only in the IP header.  (I haven't analyzed whether this may 
or may not open any new threats, because the IP address is not secured 
as it's from the header.. I think those were described at sufficient 
length already)

> to section 1.3, after the first paragraph?

Looks excellent.

> IKEv2 had done the reliability/windowing parts slightly

That's a bit unfortunate but it's fine with me..

> should be a MAY, SHOULD or MUST).

My reasoning above was, could an implementer try to optimize the 
protocol so that it will only send NO_NATS_ALLOWED with some but not 
all update messages (saving bits).  I.e., would the processing be any 
different for the exchange responder if NO_NATS_ALLOWED was sometimes 
present and sometimes not.

Hence I proposed a MUST implying "if you are going to send 
NO_NATS_ALLOWED, you have to send it *every time*, instead of just 
when you feel like it".

But if folks want to leave this a bit more open, that's fine with me..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 20 Sep 2005 15:23:28 -0700

===> The reason IKEv2 NAT detection payloads includes only the hash and
not the actual addresses is to hide the internal addresses. But this is lost with
MOBIKE because the initiator has to include these addresses in 
ADDITIONAL_ADDRESS notification. So, including the hash or real
address in the notification payloads doesn't matter. To be consistent (as we
are using NAT-D payloads from IKEv2), we might as well use the same
hash and also not be algo-agile :-)

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Sep 2005 10:05:37 +0200

=> IMHO this problem is only for MOBIKE itself (where a private of
a node behind a NAT has no meaning, i.e., it can put anything) but
not for NAT detection/prevention: I asked why NAT detection
uses a hash and not the addresses themselves and the answer was
exactly because some people were concerned that NAT detection would
reveal the internal topology (so a) applies in the real world).

   
=> there is a point about this: I'd like to drop the "middle ground",
i.e., to make the usage of either NAT detection or NAT prevention
mandatory. My idea is to get a mandatory protection of the addresses
in IP headers (as they'll become the endpoint addresses of IPsec SAs)
but your argument is good too.

   
=> this opens a threat what I called the "transient pseudo-NAT attack"
but it is not a new threat, just an ignored threat. BTW, it is easy
to fix: the addresses in the IP header should simply be reflected in
some way into the IKE payload. This is why I propose to enforce the
usage of NAT detection/prevention which does that for the first exchange.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 Sep 2005 18:33:37 +0300

Pekka Savola wrote:

> a) some people will be (at least slightly) concerned that MOBIKE will 
> reveal the internal topology of the site. This may or may not be a big 
> issue (especially as probably the most IPsec sessions will go to at 
> least semi-trusted nodes), but if we don't state it now, someone is 

Agreed.

> This may be one issue where an explicit warning might be useful.

Yes. I'd be even happier if we were able to know
which addresses are behind a NAT, but...

> aggressive you should be to start with..

This would be useful to specify, I think.

> early review from more folks in the sec area).

I think its fine to say the algorithm is "fixed" and that this
is something inherited from main IKEv2 spec.

But note that there's a difference in the algorithm being
fixed as a part of the the protocol versus fixing an algorithm
in an identifier (as in Julien's draft that you pointed) - there
may be ways of upgrading the protocol but identifier upgrading
is much harder.

> should be readable as well.

Close call, but I think I'd rather see one big section 2.3
than a set of sub-subsections.

> But if folks want to leave this a bit more open, that's fine with me..

I'd rather see the if-you-do-this-then-you-need-to-do-it-in-every-message
approach. But I'm not sure if there's need for a MUST; SHOULD appears
sufficient here.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Sep 2005 18:26:36 +0300

>   will or will not work is not done in this document.
Works for me.

>   requests for at least five minutes before giving up."
Ok. The key point is that the responder side should
not be aggressive in this regard.

>and NO_NATS_ALLOWED are different. The simplest solution might
Right.

>comparing them with the IP header)...
That seems simplest.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Sep 2005 18:57:25 +0300

Replying my own e-mail...

>> reveal the internal topology of the site. This may or may not be a 
>> big issue (especially as probably the most IPsec sessions will go to 
>> at least semi-trusted nodes), but if we don't state it now, someone 
>> is going to invent a fancy MOBIKE "exploit" 5 years down the road. A 

> which addresses are behind a NAT, but...

Thinking about this further, it seems that sending the
addresses as they currently are is the least bad option
here, as long as we have sufficient warnings about that.

If we want to support multiple addresses for failover,
we need to inform the peer. Yet it would be quite
hard to test all these addresses, or pairs really, to
find out which one of them have a NAT towards the other
peer.

--Jari