Subject: [karp] Supporting Authentication Trailer for OSPFv3

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 15 Oct 2010 05:06:23 +0530

Hi,

We have posted the new version of this draft for the WG to review.

Changes from -00:

o Uses a new option bit (AT) present in the Hellos and DDs to indicate that the router will use an Authentication trailer in all OSPFv3 packets on that link. This will obviously be negotiated and the routers will only do this if both the routers turn on the AT bit.

o Describes where the new authentication trailer is placed wrt link local signaling (LLS) block defined in RFC5613.

o Some editorial changes.

Acee, Vishwas and Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bhatia, Manav (Manav)
> Sent: Wednesday, September 29, 2010 4.50 AM
> To: [email-masked]
> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt
> 
> 
> Hi,
> 
> Proposing another mechanism for doing non Ipsec 
> authentication for OSPFv3. In this proposal the OSPFv3 
> authentication information is appended to the OSPFv3 packet 
> and is not considered a part of the protocol payload; it is 
> instead included in the IPv6 packet's payload length.
> 
> The mechanism described is very similar to how it is done for 
> OSPFv2 and implementations can reuse most of the existing 
> code for authenticating OSPFv2.
> 
> So whats the difference between this and the 
> draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt?
> 
> The main difference is that the latter introduces a new IPv6 
> extension header that can be used by all protocols that want 
> to use non IPSec security. The main issue that I see is that 
> while it is generic I don't see too many applications that 
> might want to use this. The advantage of the new mechanism is 
> that its restricted to OSPFv3 and is also backward 
> compatible. Implementations that don't support this extension 
> can continue to ignore this trailer attached to the OSPFv3 payload.
> 
> The other difference is regarding the code reusability. In 
> the new mechanism (Authentication Trailer) very little new 
> code needs to be added, while the earlier (Generic 
> Authentication Header) mechanism would require new source 
> code to be added. 
> 
> Would be great if the WG can review this document!
> 
> Cheers, Manav
> 
> ----- Forwarded Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Tue, September 28, 2010 11:15:01 PM
> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>     Title        : Supporting Authentication Trailer for OSPFv3 
>     Author(s)    : M. Bhatia, V. Manral
>     Filename    : draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>     Pages        : 12
>     Date        : 2010-9-28
>     
> Currently OSPFv3 uses IPsec for authenticating the protocol 
>       packets. There however are some environments (mobile ad-hoc), 
>       where IPsec is difficult to configure and maintain, and this 
>       mechanism cannot be used. This draft proposes an alternative 
>       mechanism that can be used so that OSPFv3 does not depend upon 
>       IPsec for security.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t
> railer-ospfv3-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
> 
>  
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: mark Brown <[email-masked]>
Date: Sat, 16 Oct 2010 02:06:51 +0530

Hi Manav,

I think this is a good idea and something that was long due.

Mark

On Fri, Oct 15, 2010 at 5:06 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Oct 2010 14:05:50 -0400

Hi,

Though the spirit of the draft is good, I have few comments on draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt. 

1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP?? 

2. Sec 2.2 
   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

3. Sec 3:
   - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit?
   - Do you need to consider any thing in draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs
     (this could be important as in future it should be tied to AKMs for RPs?)
   - Probably, it's better to be more than  8 bit to facilitate association lkup from the DB.

4. Sec 4.1

   - Figure-3 (Reserved , instead of 0?)
   - Key-ID length inconsistency
 
5. Sec 4.2
    
   - I understand the proposal made is similar to OSPFv2 - but as this as any way new for OSPF3 does it have to be limited to HMAC-xxx?
     Can AES-XCBC-xx  be considered (to give more choice and for differentiation) 
        - not questioning HMAC-SHA-256, HMAC-SHA-384 etc..
        - as said to facilitate more options (in-built crypto accelerators)

6. Sec 4.3

   - It would be better if this sections show what is input/output to the crypto and what is authenticated through 1-2 figures?
   - Probably HMAC/crypto aspect can be as part of Appendix (..you can keep the APAD aspect here)

7. Would it be better to include IPv6 header too as part of OSPF3 packet (..not only as current available AH option  gives this protection)
   
Thanks,
Uma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, October 14, 2010 4:36 PM
To: [email-masked]; [email-masked]
Subject: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi,

Changes from -00:

Acee, Vishwas and Manav

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Bhatia, Manav (Manav)
> Proposing another mechanism for doing non Ipsec authentication for 
> OSPFv3. In this proposal the OSPFv3 authentication information is 
> appended to the OSPFv3 packet and is not considered a part of the 
> protocol payload; it is instead included in the IPv6 packet's payload 
> length.
> 
> OSPFv2 and implementations can reuse most of the existing code for 
> authenticating OSPFv2.
> 
> The main difference is that the latter introduces a new IPv6 extension 
> header that can be used by all protocols that want to use non IPSec 
> security. The main issue that I see is that while it is generic I 
> don't see too many applications that might want to use this. The 
> advantage of the new mechanism is that its restricted to OSPFv3 and is 
> also backward compatible. Implementations that don't support this 
> extension can continue to ignore this trailer attached to the OSPFv3 
> payload.
> 
> The other difference is regarding the code reusability. In the new 
> mechanism (Authentication Trailer) very little new code needs to be 
> added, while the earlier (Generic Authentication Header) mechanism 
> would require new source code to be added.
>

---

From: mark Brown <[email-masked]>
Date: Tue, 19 Oct 2010 04:02:00 +0530

> Though the spirit of the draft is good, I have few comments on draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt.

+1. I think its a good idea.

> 1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP??

I suspect its a typo and the authors really meant 4552.

>   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

I think the requirement is just to move away from IPSec which has
proven difficult to deploy in the field.

I'll let the authors comment on the other questions.

> 7. Would it be better to include IPv6 header too as part of OSPF3 packet (..not only as current available AH option  gives this protection)

While draft-ietf-karp-threats-reqs-01.txt states that routing
protocols must protect the IP header, I dont think the WG has yet
reached a consensus on this particular issue. NOTE that this draft is
still under discussion and has not yet been finalized.

Mark

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Oct 2010 18:56:36 -0400

>   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

I think the requirement is just to move away from IPSec which has proven difficult to deploy in the field.

Yeah, right. Got this. I should have been more specific.  I was  thinking as mentioned in other comments - why the AUTH_trailer/choice-of-auth-algos/auth-scope-of-the packet/etc..have to be similar to OSPFv2 as there is 
  -  no  backward compatibility issue
  -  this can well address identified/potential weaknesses in OSPFv2 auth (as seen in ip-header/src protection draft) and 
  -  future flexibility (auth type)
  -  need to anyways align to/consider auto-key-management requirements

Thanks,
Uma 

>> extension header that can be used by all protocols that want to use 
>> non IPSec security. The main issue that I see is that while it is 
>> generic I don't see too many applications that might want to use 
>> this. The advantage of the new mechanism is that its restricted to 
>> OSPFv3 and is also backward compatible. Implementations that don't 
>> support this extension can continue to ignore this trailer attached 
>> to the OSPFv3 payload.
>>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 19 Oct 2010 06:26:05 +0530

Hi Uma,

Thanks for the comments.
 
> 1. Page 3 - Sec 1 - I saw couple of places referencing 

My bad - it should have been RFC 4552 - "Authentication/Confidentiality for OSPFv3".

> that this has to be similar to OSPFv2?

It isnt. We're first trying to bring it at par with OSPFv2. Once the WG agrees that its something that they would want to work on we can introduce other changes. 

>    - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit?

Thanks for catching this - will fix the figure in the next version.

>    - Do you need to consider any thing in 
> draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs

We are suggesting a 32 bit Key ID, so I guess that would take care of this too.

>    - Figure-3 (Reserved , instead of 0?)

Yes, will do.

>    - Key-ID length inconsistency

Yup!

>  
> 5. Sec 4.2
>     
>    - I understand the proposal made is similar to OSPFv2 - 
> but as this as any way new for OSPF3 does it have to be 
> limited to HMAC-xxx?

Yes, this definitely can be done. 

Currently OSPFv2 only supports HMAC. Its in my TODO list to write a small proposal about how OSPFv2 and OSPFv3 can use AEC-XCBC-xx algorithms for authenticating their protocol packets. I don't think there's any hurry as most vendors are still implementing rfc 5709.

> 
> 6. Sec 4.3
> 
>    - It would be better if this sections show what is 
> input/output to the crypto and what is authenticated through 
> 1-2 figures?
> 7. Would it be better to include IPv6 header too as part of 
> OSPF3 packet (..not only as current available AH option  
> gives this protection)

As I said earlier, I would first like to see if the WG is interested in working on a non IPSec authentication mechanism for OSPFv3. These things that can be sorted out once we have a go-ahead.

Cheers, Manav

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Oct 2010 09:41:23 -0400

I've dropped the OSPF group from the CC list as I'm following up in part
from a conversation at the last KARP meeting.

Manav, your draft looks very interesting.  I definitely think that
protecting the IP address is an important addition to OSPF
authentication. As you helped us point out in
draft-hartman-ospf-analysis,an attacker who can observe packets can
destroy an adjacency in at least one direction simply by flipping the IP
addresses around.

Your draft doesn't handle what you described as inter-connection replay
protection.
In particular, the same key is used for all traffic, and the sequence
space is not subdivided.

If you use a time stamp as a sequence number, you are vulnerable to
significant denial of service attacks using intra-connection replays.

However, if you use a per-packet sequence number, you will eventually
run out of sequence numbers and wrap. One problem is that your
adjacencies go down when you wrap.  Another problem is that an attacker
who captured one of your old packets with a higher sequence number can
replay it after  the wrap and bring down your adjacency.

Your draft doesn't fix this problem.

we could decide we're not going to fix inter-connection replay issues. I
think that would be a huge mistake. We learned at the unwanted traffic
workshop that DOS concerns with routing protocols are a huge concern and
a powerful attacker tool. I think that is very much still true today. I
think it is especially true on enterprise and campus networks.

If we're going to solve this problem, we need to figure out where.  Eric
and Gregory were having a discussion about this during the last KARP
meeting.  Eric said that in order to use the key derivation process that
Gregory favored, there would need to be some sort of nonce
exchange. Eric was concerned that the routing protocols would not
change/did not already have the mechanisms to make this possible.

Let's take a look at how this could work in your draft. Let's assume
that in addition to sending a sequence number you sent a random nonce
that was constant until a peer reboots or needs to change its sequence
number.  Routers would need to keep track of the nonce in the neighbor
table and would also need to have some exchange  for proving liveness of
a nonce.

Here's how proving liveness would work. Router A receives a packet
including nonce and sequence number from B. A will be able to use the
nonce and sequence number to know if future packets from B are
replays. However A needs to know if this nonce is really B's current
nonce or if the initial packet is a replay. So, A needs to somehow get B
to send it a packet including fresh information provided by A along with
its current nonce. This could either be a new exchange or something
integrated into the hello process. It's possible that aspects already
present in the OSPF protocol could be used to accomplish this.  For
example, if we could convince ourselves that replays prior to an
adjacency actually reaching database exchange are harmless, perhaps we
could do something based off the database exchange or the like without
introducing any new messages.

It seems that if we're going to do this, we should do it in your draft.
Alternatively we could decide that adding the sort of nonces Gregory is
looking for is not something we can do.  In that case, I think we can
only get inter-connection replay with a KMP. Some of the reasoning here
is discussed in section 2.1 of draft-hartman-karp-mrkmp.

I'd appreciate your thoughts.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Oct 2010 10:21:22 -0400

Just extracting one item from this interesting note from Sam.
Is there a difference in impact / concern between DoS of the routing 
system by attackers locating in arbitrary places on the net and DoS by 
attackers with packet manipulation (capture and selective replay at 
least) capability on the link?
Remote DoS (and therefore remote DDoS) is clearly an issue we need to be 
very aware of.
But, if an attacker has a presence on link, it seems that the damage he 
can cause is inherently much larger than adjacency disruption, since he 
probably has control of a router on that link.
(To be clear, this is just my personal guess from my knothole looking at 
things.)

Yours,
Joel

On 10/20/2010 9:41 AM, Sam Hartman wrote:
...
> think it is especially true on enterprise and campus networks.
...

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Oct 2010 11:00:55 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> Just extracting one item from this interesting note from Sam.
    Joel> Is there a difference in impact / concern between DoS of the
    Joel> routing system by attackers locating in arbitrary places on
    Joel> the net and DoS by attackers with packet manipulation (capture
    Joel> and selective replay at least) capability on the link?  Remote
    Joel> DoS (and therefore remote DDoS) is clearly an issue we need to
    Joel> be very aware of.  But, if an attacker has a presence on link,
    Joel> it seems that the damage he can cause is inherently much
    Joel> larger than adjacency disruption, since he probably has
    Joel> control of a router on that link.  (To be clear, this is just
    Joel> my personal guess from my knothole looking at things.)

In networks with broadcast domains and some layer 2 infrastructure, it
doesn't follow at allthat the attacker has control of a router on the
link at least as far as I can see.  Especially given that the traffic is
multicast, if you're part of the broadcast domain you will be able to
observe and replay.  So, for core SP networks, this may not be a huge
issue.  For data center, enterprise and campus networks, at least my
experience is that there are often devices who would be in a position to
observe who would not be routers.

I think this could get to be even more significant of an issue for
broadcast domains that have components that are wireless at layer 2.  I
can't think of lots of situations where such networks would tend not to
be stubs. I'm assuming that breaking adjacencies between say the DR and
BDR on a stub network with just those two routers probably isn't a huge
deal.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 20 Oct 2010 21:43:58 +0530

Hi Sam,

I changed the subject since the discussion seems to be related to http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-00 and not http://tools.ietf.org/html/draft-bhatia-manral-auth-trailer-ospfv3-01 as the subject would lead one to believe.
 
[clipped]
 
> adjacencies go down when you wrap.  Another problem is that 

I have rarely seen adjacencies going down because of crypto sequence space wrapping. This can be trivially fixed by increasing the sequence number space to 64 bits. 

> an attacker

Yes, this is a problem that we must address, and I agree this draft doesn't do that.

> think that would be a huge mistake. We learned at the unwanted traffic

I agree.

> Let's take a look at how this could work in your draft. Let's assume

Ok, so it seems you are after all discussing draft-bhatia-manral-auth-trailer-ospfv3-01. I am confused because its draft-bhatia-karp-ospf-ip-layer-protection-00 that discusses how OSPF can be protected against attacks on the IP header. 

We could however merge the two together and recommend Apad to be derived from the IP header in draft-bhatia-manral-auth-trailer-ospfv3-01 too.

> table and would also need to have some exchange  for proving 

.. and this is the tricky part. Assume that A and B are in a steady state and B now receives a blank HELLO from A with a new nonce. How can B confidently know that its not an old HELLO that's being replayed but a genuine packet issued by A (probably as a result of a reboot, etc). By protecting the IP header using Apad as described in draft-bhatia-karp-ospf-ip-layer-protection-00 we can be assured that its not some other rogue router sending us a new HELLO with a new nonce. However its as you said, not fixing the replay attack problem.

Let me think over this ..

Cheers, Manav

> examp ency actually reaching database exchange are harmless, perhaps we

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 20 Oct 2010 17:52:59 -0400

> workshop that DOS concerns with routing protocols are a huge concern 
> and a powerful attacker tool. I think that is very much still true 
> today. I think it is especially true on enterprise and campus 
> networks.
> 
> If we're going to solve this problem, we need to figure out where.  
> Eric and Gregory were having a discussion about this during the last 
> KARP meeting.  Eric said that in order to use the key derivation 
> process that Gregory favored, there would need to be some sort of 
> nonce exchange. Eric was concerned that the routing protocols would 
> not change/did not already have the mechanisms to make this possible.
> 

> table and would also need to have some exchange  for proving liveness 
> of a nonce.

I guess, replay attack is one of the difficult to solve..
With AKM, you get a new NONCE every time fresh auth key is generated and also before sequence number wrap fresh keys could be generated (if life time is configured too big).
Are we thinking to solve this with out AKM??

Thanks,
Uma

---

From: mark Brown <[email-masked]>
Date: Fri, 22 Oct 2010 05:43:47 +0530

Uma,

> Are we thinking to solve this with out AKM??

If you look at the design guide it states that the phase I of work on
any routing protocol would involve fixing the manual keying management
procedures. We need to refer to the karp-threats-and-reqs document for
the list of requirements for the phase I. Moving to AKM is the II,
final phase.

Mark

---

From: Glen Kent <[email-masked]>
Date: Tue, 26 Oct 2010 05:38:12 +0530

Sam and others,

> the list of requirements for the phase I. Moving to AKM is the II,

Does this mean that we will be fixing all replay issues, IP header
issues, etc. that have been identified till date, _first_ with manual
keying, and then _later_ with a key management mechanism in place? If
the plan is to anyways move to a fully automated key management system
then whats the point in expending energy in defining standards for
fixing these known issues with manual keying. Are we doing this work
so that there is a smoother rollover from manual keying to key
management or is it because we're not sure if operators will ever move
to a fully automated key management mechanism, or something else?

Glen

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 25 Oct 2010 20:27:57 -0400

Hi Glen,

> the list of requirements for the phase I. Moving to AKM is the II, 

Glen> Does this mean that we will be fixing all replay issues, IP header issues, etc. that have been identified till date, _first_ with manual keying, and then _later_ with a key management Glen> mechanism in place? If the plan is to anyways move to a fully automated key management system then whats the point in expending energy in defining standards for fixing these known issues Glen> with manual keying. 

I think - discussion around IP header issues is independent of AKM/Manual keying but that is not the case with replay attacks.

Glen> Are we doing this work so that there is a smoother rollover from manual keying to key management or is it because we're not sure if operators will ever move to a fully  automated key management mechanism, or something else?

I guess it should be for both the reason you mentioned, if I understand the threat document. Well, would like to hear the scope from authors..

Thanks,
Uma

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Oct 2010 06:38:02 -0400

>>>>> "Glen" == Glen Kent <[email-masked]> writes:

    Glen> Sam and others,
    >>> I guess, replay attack is one of the difficult to solve..  With
    >>> AKM, you get a new NONCE every time fresh auth key is generated
    >>> and also before sequence number wrap fresh keys could be
    >>> generated (if life time is configured too big).  Are we thinking
    >>> to solve this with out AKM??
    >> 
    >> If you look at the design guide it states that the phase I of
    >> work on any routing protocol would involve fixing the manual
    >> keying management procedures. We need to refer to the
    >> karp-threats-and-reqs document for the list of requirements for
    >> the phase I. Moving to AKM is the II, final phase.

    Glen> Does this mean that we will be fixing all replay issues, IP
    Glen> header issues, etc. that have been identified till date,
    Glen> _first_ with manual keying, and then _later_ with a key
    Glen> management mechanism in place? If the plan is to anyways move
    Glen> to a fully automated key management system then whats the
    Glen> point in expending energy in defining standards for fixing
    Glen> these known issues with manual keying. Are we doing this work
    Glen> so that there is a smoother rollover from manual keying to key
    Glen> management or is it because we're not sure if operators will
    Glen> ever move to a fully automated key management mechanism, or
    Glen> something else?

I'd assume we're going to look at what it would take to fix both ways
and then decide.  Dacheng and I have put together a proposal for how to
fix it with automated key management in draft-hartman-karp-mrkmp.
Manav, Dacheng and myself have been discussing fixes that work for
manual key management off-list.

If you fix it for manual key management, then it works even if someone
never deploys automated key management.  However it may introduce
complexity.
So, we're going to have to balance things.

If we find the phases in the design guide are wrong, we can change them
so long as we stay within the charter.

--Sam