Re: Multi-homed clients and BGP timers

[Olof Kasselstrand]

We have customers in the same way you do. We only use Cisco (both pop
routers and managed cpe) and use

neighbor xxx.xxx.xxx.xxx timers 5 15

on the pop routers with great success. We haven't found any drawback so far.

// OK

On Sat, May 23, 2009 at 12:45 AM, Steve Bertrand  wrote:
> Hi all,
>
> I've got numerous single-site 100Mb fibre clients who have backup SDSL
> links to my PoP. The two services terminate on separate
> distribution/access routers.
>
> The CPE that peers to my fibre router sets a community, and my end sets
> the pref to 150 based on it. The CPE also sets a higher pref for
> prefixes from the fibre router. The SDSL router to CPE leaves the
> default preference in place. Both of my PE gear sends default-originate
> to the CPE. There is (generally) no traffic that should ever be on the
> SDSL link while the fibre is up.
>
> Both of the PE routers then advertise the learnt client route up into
> the core:
>
> *>i208.70.107.128/28
>                    172.16.104.22             0    150      0 64762 i
> * i                 172.16.104.23             0    100      0 64762 i
>
> My problem is the noticeable delay for switchover when the fibre happens
> to go down (God forbid).
>
> I would like to know if BGP timer adjustment is the way to adjust this,
> or if there is a better/different way. It's fair to say that the fibre
> doesn't 'flap'. Based on operational experience, if there is a problem
> with the fibre network, it's down for the count.
>
> While I'm at it, I've got another couple of questions:
>
> - whatever technique you might recommend to reduce the convergence
> throughout the network, can the same principles be applied to iBGP as well?
>
> - if I need to down core2, what is the quickest and easiest way to
> ensure that all gear connected to the cores will *quickly* switch to
> preferring core1?
>
> Steve
>
>

Re: AH or ESP

[Jack Kohn]

Glen,

IPSECME WG  at IETF
is actually working on the exact issue that you have described (unable to
deep inspect ESP-NULL packets).

You can look at
draft-ietf-ipsecme-traffic-visibility-02for
more details.

Jack

On Sat, May 23, 2009 at 5:06 AM, Glen Kent  wrote:
> Yes, thats what i had meant !
>
> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
>  wrote:
>>
>> On Fri, May 22, 2009 at 1:04 PM, Glen Kent  wrote:
>> > Hi,
>> >
>> > It is well known in the community that AH is NAT unfriendly while ESP
>> > cannot
>> > be filtered, and most firewalls would not let such packets pass. I am
>> > NOT
>>
>> 'the content of the esp packet can't be filtered in transit' I think
>> you mean... right?
>>
>> > interested in encrypting the data, but i do want origination
>> > authentication
>> > (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
>> > that both have some issues?
>> >
>> > Thanks,
>> > Glen
>> >
>
>

Re: Multi-homed clients and BGP timers

[Florian Weimer]

* Iljitsch van Beijnum:

> 30 60 isn't a good choice because that means that after 30.1 seconds a
> keepalive comes in and then after 60.0 seconds the session will expire
> while the second one would be there in 60.1 seconds.

Wouldn't the underlying TCP retry sooner than that?

IXP BGP timers (was: Multi-homed clients and BGP timers)

[Chris Caputo]

What's the BCP for BGP timers at exchange points?

I imagine if everyone did something low like 5-15 rather than the default 
60-180, CPU usage increase could be significant given a high number peers.

Keeping in mind that "bgp fast-external-failover" is of no use at an 
exchange since the fabric is likely to stay up when a peer has gone down, 
and BFD would need to be negotiated peer-by-peer, is there a 
recommendation other than the default 60-180?

Would going below 60-180 without first discussing it with your peers, tend 
to piss them off?

Chris

Re: Multi-homed clients and BGP timers

[Danny McPherson]

On May 25, 2009, at 11:33 AM, Florian Weimer wrote:


* Iljitsch van Beijnum:

30 60 isn't a good choice because that means that after 30.1  
seconds a
keepalive comes in and then after 60.0 seconds the session will  
expire

while the second one would be there in 60.1 seconds.


Wouldn't the underlying TCP retry sooner than that?


I suspect that given update messages serve as implicit
keepalives, it's _extremely rare that an actual keepalive
message is needed in global routing environments.

-danny

Re: IXP BGP timers (was: Multi-homed clients and BGP timers)

[Andree Toonk]

Hi Chris,

.-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo 
wrote:

> Would going below 60-180 without first discussing it with your peers, tend 
> to piss them off?

60-180 is fairly conservative. 60-180 is the Cisco default I believe, however
Junipers defaults are 30-90. I never pissed anyone off with that ;)

Cheers,
 Andree

RE: IXP BGP timers (was: Multi-homed clients and BGP timers)

[John.Herbert]

For those in multivendor environments, it's worth also being aware that since 
7.6R1 JunOS sets the minimum BGP hold timer to 20 seconds. If I were creating a 
standard timer config to deploy consistently on customer peers (and needed 
something on the fast side in timer terms) I would need to take that into 
account.

(And yes, there is of course a way to override the 20s hold timer, but it's not 
a supported config last time I checked)

j.


From: Andree Toonk [andree+na...@toonk.nl]
Sent: Monday, May 25, 2009 2:33 PM
To: Chris Caputo
Cc: nanog@nanog.org
Subject: Re: IXP BGP timers (was: Multi-homed clients and BGP timers)

Hi Chris,

.-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo 
wrote:

> Would going below 60-180 without first discussing it with your peers, tend
> to piss them off?

60-180 is fairly conservative. 60-180 is the Cisco default I believe, however
Junipers defaults are 30-90. I never pissed anyone off with that ;)

Cheers,
 Andree

Re: Multi-homed clients and BGP timers

[Florian Weimer]

* Danny McPherson:

> On May 25, 2009, at 11:33 AM, Florian Weimer wrote:
>
>> * Iljitsch van Beijnum:
>>
>>> 30 60 isn't a good choice because that means that after 30.1
>>> seconds a
>>> keepalive comes in and then after 60.0 seconds the session will
>>> expire
>>> while the second one would be there in 60.1 seconds.
>>
>> Wouldn't the underlying TCP retry sooner than that?
>
> I suspect that given update messages serve as implicit
> keepalives, it's _extremely rare that an actual keepalive
> message is needed in global routing environments.

See the subject of this thread. 8-) I don't think we're talking about
full tables here, so you actually have to rely on keepalives
(plus TCP retransmits).

Re: AH or ESP

[Merike Kaeo]

Yeah - the main issue with using ESP is that there's a trailer at end  
of packet that tells you more info to determine whether you can  
inspect the packet.  So you have to look at the end of the packet to  
see whether ESP is using encryption or null-encryption (i.e. just  
integrity protection).  Some vendors do have proprietary mechanisms  
in software for now which doesn't scale.  The work below will  
hopefully lock into a solution where hw can be built to quickly  
determine if ESP is used for integrity only.


AH is not really widely used (except for OSPFv3 since early  
implementations locked in on AH when the standard said to use IPsec  
for integrity protection).  Note that a subsequent standard now  
exists which explicitly states that ESP-Null MUST be supported and AH  
MAY be supported.  But how many folks are actually running OSPF for a  
v6 environment and using IPsec to protect the communicating peers?   
Some but not many (yet).


Personally, I'd stick with ESP.  AH complicates matters  
(configuration, nested environments when you do decide to also use  
ESP for encryption maybe later, NAT) and while is isn't officially  
deprecated vendors don't test it as much as ESP - at interoperability  
tests it's not stressed, at least the ones I've been to.  Ask your  
vendor(s) what they think of the work below and see where they stand  
with implementing it.


Be happy to answer any more questions offline.

- merike

On May 25, 2009, at 6:24 AM, Jack Kohn wrote:


Glen,

IPSECME WG   
at IETF
is actually working on the exact issue that you have described  
(unable to

deep inspect ESP-NULL packets).

You can look at
draft-ietf-ipsecme-traffic-visibility-02for

more details.

Jack

On Sat, May 23, 2009 at 5:06 AM, Glen Kent   
wrote:

Yes, thats what i had meant !

On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
 wrote:


On Fri, May 22, 2009 at 1:04 PM, Glen Kent   
wrote:

Hi,

It is well known in the community that AH is NAT unfriendly  
while ESP

cannot
be filtered, and most firewalls would not let such packets pass.  
I am

NOT


'the content of the esp packet can't be filtered in transit' I think
you mean... right?


interested in encrypting the data, but i do want origination
authentication
(Integrity Protection). Do folks in such cases use AH or ESP-NULL,

given

that both have some issues?

Thanks,
Glen

Re: AH or ESP

[Jack Kohn]

Not really.

Currently, you cant even look at the ESP trailer to determine if its an
encrypted or an integrity protected packet, because the trailer itself could
be encrypted.

A router, by reading the next-header field from the ESP trailer can never be
sure that its an OSPFv3 packet inside since it wouldnt know whether the
packet is encrypted or not. One could have an encrypted packet inside, for
which the next-header field turns out to be 89, but that may not necessarily
mean that its an OSPFv3 packet. It could be a VoIP packet that just happens
to look like OSPFv3 once encrypted. There is no indication sent on the wire
that says that the packet is encrypted.

So, there is no way to identify/deep inspect/filter ESP packets unless
you're the recipient, which imo is the root cause of all heart burn in the
intermediate devices like firewalls, transit routers, etc.

A couple of solutions were thrown at the WG and the current one (wesp) was
selected as the best.

I agree that we should just throw out AH and stick to one protocol which has
been extensively tested. A quick scan through some of vendors data sheets
quickly reveals that most of them dont even provide support for AH.

Jack

On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo  wrote:

> Yeah - the main issue with using ESP is that there's a trailer at end of
> packet that tells you more info to determine whether you can inspect the
> packet.  So you have to look at the end of the packet to see whether ESP is
> using encryption or null-encryption (i.e. just integrity protection).  Some
> vendors do have proprietary mechanisms in software for now which doesn't
> scale.  The work below will hopefully lock into a solution where hw can be
> built to quickly determine if ESP is used for integrity only.
>
> AH is not really widely used (except for OSPFv3 since early implementations
> locked in on AH when the standard said to use IPsec for integrity
> protection).  Note that a subsequent standard now exists which explicitly
> states that ESP-Null MUST be supported and AH MAY be supported.  But how
> many folks are actually running OSPF for a v6 environment and using IPsec to
> protect the communicating peers?  Some but not many (yet).
>
> Personally, I'd stick with ESP.  AH complicates matters (configuration,
> nested environments when you do decide to also use ESP for encryption maybe
> later, NAT) and while is isn't officially deprecated vendors don't test it
> as much as ESP - at interoperability tests it's not stressed, at least the
> ones I've been to.  Ask your vendor(s) what they think of the work below and
> see where they stand with implementing it.
>
> Be happy to answer any more questions offline.
>
> - merike
>
> On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
>
>  Glen,
>>
>> IPSECME WG  at
>> IETF
>> is actually working on the exact issue that you have described (unable to
>> deep inspect ESP-NULL packets).
>>
>> You can look at
>> draft-ietf-ipsecme-traffic-visibility-02> draft-ietf-ipsecme-traffic-visibility-02>for
>> more details.
>>
>> Jack
>>
>> On Sat, May 23, 2009 at 5:06 AM, Glen Kent  wrote:
>>
>>> Yes, thats what i had meant !
>>>
>>> On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
>>>  wrote:
>>>

 On Fri, May 22, 2009 at 1:04 PM, Glen Kent  wrote:

> Hi,
>
> It is well known in the community that AH is NAT unfriendly while ESP
> cannot
> be filtered, and most firewalls would not let such packets pass. I am
> NOT
>

 'the content of the esp packet can't be filtered in transit' I think
 you mean... right?

  interested in encrypting the data, but i do want origination
> authentication
> (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
>
 given
>>
>>> that both have some issues?
>
> Thanks,
> Glen
>
>
>>>
>>>
>

Re: AH or ESP

[Glen Kent]

Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
now being supported only for legacy reasons? The only negative with
ESP-NULL afaik was that it could not be filtered (since packets could
not be inspected), however, this changes with the "wesp" proposal.
Also, the fact that AH is NAT unfriendly should be the final nail in
its coffin.

Any reasons why we still see it around?

Thanks,
Glen

On Tue, May 26, 2009 at 5:44 AM, Jack Kohn  wrote:
> Not really.
>
> Currently, you cant even look at the ESP trailer to determine if its an
> encrypted or an integrity protected packet, because the trailer itself could
> be encrypted.
>
> A router, by reading the next-header field from the ESP trailer can never be
> sure that its an OSPFv3 packet inside since it wouldnt know whether the
> packet is encrypted or not. One could have an encrypted packet inside, for
> which the next-header field turns out to be 89, but that may not necessarily
> mean that its an OSPFv3 packet. It could be a VoIP packet that just happens
> to look like OSPFv3 once encrypted. There is no indication sent on the wire
> that says that the packet is encrypted.
>
> So, there is no way to identify/deep inspect/filter ESP packets unless
> you're the recipient, which imo is the root cause of all heart burn in the
> intermediate devices like firewalls, transit routers, etc.
>
> A couple of solutions were thrown at the WG and the current one (wesp) was
> selected as the best.
>
> I agree that we should just throw out AH and stick to one protocol which has
> been extensively tested. A quick scan through some of vendors data sheets
> quickly reveals that most of them dont even provide support for AH.
>
> Jack
>
> On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo  wrote:
>
>> Yeah - the main issue with using ESP is that there's a trailer at end of
>> packet that tells you more info to determine whether you can inspect the
>> packet.  So you have to look at the end of the packet to see whether ESP is
>> using encryption or null-encryption (i.e. just integrity protection).  Some
>> vendors do have proprietary mechanisms in software for now which doesn't
>> scale.  The work below will hopefully lock into a solution where hw can be
>> built to quickly determine if ESP is used for integrity only.
>>
>> AH is not really widely used (except for OSPFv3 since early implementations
>> locked in on AH when the standard said to use IPsec for integrity
>> protection).  Note that a subsequent standard now exists which explicitly
>> states that ESP-Null MUST be supported and AH MAY be supported.  But how
>> many folks are actually running OSPF for a v6 environment and using IPsec to
>> protect the communicating peers?  Some but not many (yet).
>>
>> Personally, I'd stick with ESP.  AH complicates matters (configuration,
>> nested environments when you do decide to also use ESP for encryption maybe
>> later, NAT) and while is isn't officially deprecated vendors don't test it
>> as much as ESP - at interoperability tests it's not stressed, at least the
>> ones I've been to.  Ask your vendor(s) what they think of the work below and
>> see where they stand with implementing it.
>>
>> Be happy to answer any more questions offline.
>>
>> - merike
>>
>> On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
>>
>>  Glen,
>>>
>>> IPSECME WG  at
>>> IETF
>>> is actually working on the exact issue that you have described (unable to
>>> deep inspect ESP-NULL packets).
>>>
>>> You can look at
>>> draft-ietf-ipsecme-traffic-visibility-02>> draft-ietf-ipsecme-traffic-visibility-02>for
>>> more details.
>>>
>>> Jack
>>>
>>> On Sat, May 23, 2009 at 5:06 AM, Glen Kent  wrote:
>>>
 Yes, thats what i had meant !

 On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
  wrote:

>
> On Fri, May 22, 2009 at 1:04 PM, Glen Kent  wrote:
>
>> Hi,
>>
>> It is well known in the community that AH is NAT unfriendly while ESP
>> cannot
>> be filtered, and most firewalls would not let such packets pass. I am
>> NOT
>>
>
> 'the content of the esp packet can't be filtered in transit' I think
> you mean... right?
>
>  interested in encrypting the data, but i do want origination
>> authentication
>> (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
>>
> given
>>>
 that both have some issues?
>>
>> Thanks,
>> Glen
>>
>>


>>
>

Re: AH or ESP

[Merike Kaeo]

Coming from someone who is somewhat jaded.politics.

Realistically there are some folks who believe that not having the IP  
header (and with v6 also the option headers) integrity protected is  
an issue.  It's not.  You have more risk of operation issues from  
adding complexity of AH.note that the fields that are modified in  
transit in the headers are NOT included in the integrity protection.   
So it really becomes an issue of is the IP address protected and  
basically, yes that's done via IKE and the way security associations  
work anyhow. [if you change IP address of header you will not have  
appropriate security association match]


Once the technology is there to quickly differentiate ESP-Null from  
ESP-encrypted packets the argument of "but you can inspect AH  
packets" becomes irrelevant.


- merike

On May 25, 2009, at 5:23 PM, Glen Kent wrote:


Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
now being supported only for legacy reasons? The only negative with
ESP-NULL afaik was that it could not be filtered (since packets could
not be inspected), however, this changes with the "wesp" proposal.
Also, the fact that AH is NAT unfriendly should be the final nail in
its coffin.

Any reasons why we still see it around?

Thanks,
Glen

On Tue, May 26, 2009 at 5:44 AM, Jack Kohn   
wrote:

Not really.

Currently, you cant even look at the ESP trailer to determine if  
its an
encrypted or an integrity protected packet, because the trailer  
itself could

be encrypted.

A router, by reading the next-header field from the ESP trailer  
can never be
sure that its an OSPFv3 packet inside since it wouldnt know  
whether the
packet is encrypted or not. One could have an encrypted packet  
inside, for
which the next-header field turns out to be 89, but that may not  
necessarily
mean that its an OSPFv3 packet. It could be a VoIP packet that  
just happens
to look like OSPFv3 once encrypted. There is no indication sent on  
the wire

that says that the packet is encrypted.

So, there is no way to identify/deep inspect/filter ESP packets  
unless
you're the recipient, which imo is the root cause of all heart  
burn in the

intermediate devices like firewalls, transit routers, etc.

A couple of solutions were thrown at the WG and the current one  
(wesp) was

selected as the best.

I agree that we should just throw out AH and stick to one protocol  
which has
been extensively tested. A quick scan through some of vendors data  
sheets

quickly reveals that most of them dont even provide support for AH.

Jack

On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo  wrote:

Yeah - the main issue with using ESP is that there's a trailer at  
end of
packet that tells you more info to determine whether you can  
inspect the
packet.  So you have to look at the end of the packet to see  
whether ESP is
using encryption or null-encryption (i.e. just integrity  
protection).  Some
vendors do have proprietary mechanisms in software for now which  
doesn't
scale.  The work below will hopefully lock into a solution where  
hw can be

built to quickly determine if ESP is used for integrity only.

AH is not really widely used (except for OSPFv3 since early  
implementations

locked in on AH when the standard said to use IPsec for integrity
protection).  Note that a subsequent standard now exists which  
explicitly
states that ESP-Null MUST be supported and AH MAY be supported.   
But how
many folks are actually running OSPF for a v6 environment and  
using IPsec to

protect the communicating peers?  Some but not many (yet).

Personally, I'd stick with ESP.  AH complicates matters  
(configuration,
nested environments when you do decide to also use ESP for  
encryption maybe
later, NAT) and while is isn't officially deprecated vendors  
don't test it
as much as ESP - at interoperability tests it's not stressed, at  
least the
ones I've been to.  Ask your vendor(s) what they think of the  
work below and

see where they stand with implementing it.

Be happy to answer any more questions offline.

- merike

On May 25, 2009, at 6:24 AM, Jack Kohn wrote:

 Glen,


IPSECME WG  at

IETF
is actually working on the exact issue that you have described  
(unable to

deep inspect ESP-NULL packets).

You can look at
draft-ietf-ipsecme-traffic-visibility-02for
more details.

Jack

On Sat, May 23, 2009 at 5:06 AM, Glen Kent   
wrote:



Yes, thats what i had meant !

On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow
 wrote:



On Fri, May 22, 2009 at 1:04 PM, Glen Kent  
 wrote:



Hi,

It is well known in the community that AH is NAT unfriendly  
while ESP

cannot
be filtered, and most firewalls would not let such packets  
pass. I am

NOT



'the content of the esp packet can't be filtered in transit' I  
think

you mean... right?

 interested in encrypting the data, but i do want orig

Re: AH or ESP

[Jack Kohn]

Hmm .. besides this, AH is *never* export restricted. Also, i could be
mistaken, but isnt AH compliance mandatory in IPv6?

Earlier there were some issues in using ESP with TCP performance enhancement
proxies used in wireless networks, which couldnt deep inspect the ESP
packets to extract TCP flow IDs and seq numbers, but that should all change
with the new WESP proposal.

Jack

On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo  wrote:

> Coming from someone who is somewhat jaded.politics.
>
> Realistically there are some folks who believe that not having the IP
> header (and with v6 also the option headers) integrity protected is an
> issue.  It's not.  You have more risk of operation issues from adding
> complexity of AH.note that the fields that are modified in transit in
> the headers are NOT included in the integrity protection.  So it really
> becomes an issue of is the IP address protected and basically, yes that's
> done via IKE and the way security associations work anyhow. [if you change
> IP address of header you will not have appropriate security association
> match]
>
> Once the technology is there to quickly differentiate ESP-Null from
> ESP-encrypted packets the argument of "but you can inspect AH packets"
> becomes irrelevant.
>
> - merike
>
>
> On May 25, 2009, at 5:23 PM, Glen Kent wrote:
>
>  Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
>> now being supported only for legacy reasons? The only negative with
>> ESP-NULL afaik was that it could not be filtered (since packets could
>> not be inspected), however, this changes with the "wesp" proposal.
>> Also, the fact that AH is NAT unfriendly should be the final nail in
>> its coffin.
>>
>> Any reasons why we still see it around?
>>
>> Thanks,
>> Glen
>>
>> On Tue, May 26, 2009 at 5:44 AM, Jack Kohn  wrote:
>>
>>> Not really.
>>>
>>> Currently, you cant even look at the ESP trailer to determine if its an
>>> encrypted or an integrity protected packet, because the trailer itself
>>> could
>>> be encrypted.
>>>
>>> A router, by reading the next-header field from the ESP trailer can never
>>> be
>>> sure that its an OSPFv3 packet inside since it wouldnt know whether the
>>> packet is encrypted or not. One could have an encrypted packet inside,
>>> for
>>> which the next-header field turns out to be 89, but that may not
>>> necessarily
>>> mean that its an OSPFv3 packet. It could be a VoIP packet that just
>>> happens
>>> to look like OSPFv3 once encrypted. There is no indication sent on the
>>> wire
>>> that says that the packet is encrypted.
>>>
>>> So, there is no way to identify/deep inspect/filter ESP packets unless
>>> you're the recipient, which imo is the root cause of all heart burn in
>>> the
>>> intermediate devices like firewalls, transit routers, etc.
>>>
>>> A couple of solutions were thrown at the WG and the current one (wesp)
>>> was
>>> selected as the best.
>>>
>>> I agree that we should just throw out AH and stick to one protocol which
>>> has
>>> been extensively tested. A quick scan through some of vendors data sheets
>>> quickly reveals that most of them dont even provide support for AH.
>>>
>>> Jack
>>>
>>> On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo  wrote:
>>>
>>>  Yeah - the main issue with using ESP is that there's a trailer at end of
 packet that tells you more info to determine whether you can inspect the
 packet.  So you have to look at the end of the packet to see whether ESP
 is
 using encryption or null-encryption (i.e. just integrity protection).
  Some
 vendors do have proprietary mechanisms in software for now which doesn't
 scale.  The work below will hopefully lock into a solution where hw can
 be
 built to quickly determine if ESP is used for integrity only.

 AH is not really widely used (except for OSPFv3 since early
 implementations
 locked in on AH when the standard said to use IPsec for integrity
 protection).  Note that a subsequent standard now exists which
 explicitly
 states that ESP-Null MUST be supported and AH MAY be supported.  But how
 many folks are actually running OSPF for a v6 environment and using
 IPsec to
 protect the communicating peers?  Some but not many (yet).

 Personally, I'd stick with ESP.  AH complicates matters (configuration,
 nested environments when you do decide to also use ESP for encryption
 maybe
 later, NAT) and while is isn't officially deprecated vendors don't test
 it
 as much as ESP - at interoperability tests it's not stressed, at least
 the
 ones I've been to.  Ask your vendor(s) what they think of the work below
 and
 see where they stand with implementing it.

 Be happy to answer any more questions offline.

 - merike

 On May 25, 2009, at 6:24 AM, Jack Kohn wrote:

  Glen,

>
> IPSECME WG  at
> IETF
> is ac

Re: AH or ESP

[Merike Kaeo]

IPsec as a whole is compliance mandatory for IPv6 although for new  
version of IPv6 Node requirements that came out recently I think they  
changed that to a 'SHOULD'.  Wireless devices (phones) have issues  
with battery life when IPsec implemented.  Note that all standards  
say ESP-Null is 'MUST' (mandatory-to-implement ) algorithm and AH is  
a 'MAY' support.


Yep.integrity was specifically decoupled due to export  
restrictions on cryptography technologies used for encryption - the  
restrictions do not apply for just authentication/integrity  
cryptography.  Hence AH and ESP.   ESP-Null came about when folks  
realized AH could not traverse NATs.


- merike

On May 25, 2009, at 8:26 PM, Jack Kohn wrote:

Hmm .. besides this, AH is *never* export restricted. Also, i could  
be mistaken, but isnt AH compliance mandatory in IPv6?


Earlier there were some issues in using ESP with TCP performance  
enhancement proxies used in wireless networks, which couldnt deep  
inspect the ESP packets to extract TCP flow IDs and seq numbers,  
but that should all change with the new WESP proposal.


Jack

On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo  wrote:
Coming from someone who is somewhat jaded.politics.

Realistically there are some folks who believe that not having the  
IP header (and with v6 also the option headers) integrity protected  
is an issue.  It's not.  You have more risk of operation issues  
from adding complexity of AH.note that the fields that are  
modified in transit in the headers are NOT included in the  
integrity protection.  So it really becomes an issue of is the IP  
address protected and basically, yes that's done via IKE and the  
way security associations work anyhow. [if you change IP address of  
header you will not have appropriate security association match]


Once the technology is there to quickly differentiate ESP-Null from  
ESP-encrypted packets the argument of "but you can inspect AH  
packets" becomes irrelevant.


- merike


On May 25, 2009, at 5:23 PM, Glen Kent wrote:

Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
now being supported only for legacy reasons? The only negative with
ESP-NULL afaik was that it could not be filtered (since packets could
not be inspected), however, this changes with the "wesp" proposal.
Also, the fact that AH is NAT unfriendly should be the final nail in
its coffin.

Any reasons why we still see it around?

Thanks,
Glen

On Tue, May 26, 2009 at 5:44 AM, Jack Kohn   
wrote:

Not really.

Currently, you cant even look at the ESP trailer to determine if  
its an
encrypted or an integrity protected packet, because the trailer  
itself could

be encrypted.

A router, by reading the next-header field from the ESP trailer can  
never be
sure that its an OSPFv3 packet inside since it wouldnt know whether  
the
packet is encrypted or not. One could have an encrypted packet  
inside, for
which the next-header field turns out to be 89, but that may not  
necessarily
mean that its an OSPFv3 packet. It could be a VoIP packet that just  
happens
to look like OSPFv3 once encrypted. There is no indication sent on  
the wire

that says that the packet is encrypted.

So, there is no way to identify/deep inspect/filter ESP packets unless
you're the recipient, which imo is the root cause of all heart burn  
in the

intermediate devices like firewalls, transit routers, etc.

A couple of solutions were thrown at the WG and the current one  
(wesp) was

selected as the best.

I agree that we should just throw out AH and stick to one protocol  
which has
been extensively tested. A quick scan through some of vendors data  
sheets

quickly reveals that most of them dont even provide support for AH.

Jack

On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo  wrote:

Yeah - the main issue with using ESP is that there's a trailer at  
end of
packet that tells you more info to determine whether you can  
inspect the
packet.  So you have to look at the end of the packet to see  
whether ESP is
using encryption or null-encryption (i.e. just integrity  
protection).  Some
vendors do have proprietary mechanisms in software for now which  
doesn't
scale.  The work below will hopefully lock into a solution where hw  
can be

built to quickly determine if ESP is used for integrity only.

AH is not really widely used (except for OSPFv3 since early  
implementations

locked in on AH when the standard said to use IPsec for integrity
protection).  Note that a subsequent standard now exists which  
explicitly
states that ESP-Null MUST be supported and AH MAY be supported.   
But how
many folks are actually running OSPF for a v6 environment and using  
IPsec to

protect the communicating peers?  Some but not many (yet).

Personally, I'd stick with ESP.  AH complicates matters  
(configuration,
nested environments when you do decide to also use ESP for  
encryption maybe
later, NAT) and while is isn't officially deprecated vendors don't  
test it
as much