Re: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01

[Timothy Carlin]

Hi Dave,

Yes, I believe they have been addressed.  Thanks for checking in, my
apologies for not confirming sooner.

Best Regards,
Tim Carlin

On Mon, Jan 30, 2017 at 3:54 PM, Waltermire, David A. (Fed) <
david.walterm...@nist.gov> wrote:

> >From what I can tell, addressing this feedback is the only thing that
> needs to be done before progressing this draft to the IESG for publication.
>
> Tim,
>
> Did Tero's response address your concerns?
>
> Tero,
>
> Are you or the other authors planning to post an update based on this
> feedback?
>
> Thanks,
> Dave
>
> > -Original Message-
> > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
> > Sent: Thursday, January 12, 2017 8:03 AM
> > To: Timothy Carlin <tjcar...@iol.unh.edu>
> > Cc: ipsec@ietf.org
> > Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01
> >
> > Timothy Carlin writes:
> > > My comments:
> > >
> > > * Section 4 mentions that that 256-bit keys are raised to the SHOULD
> > > level. Should this read as these are now the MUST level as
> > > ENCR_AES_CBC and
> > > ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the
> > > [1] endnote)?
> >
> > Yes, I think this is inconsistancy caused by last edits, i.e., when we
> changed
> > the 256-bit keys to MUST, we only edited the footnote, and missed the
> text
> > in section 4.
> >
> > So correct change is:
> >
> > OLD:
> >
> >   In that sense 256 bit keys
> >status has been raised from MAY in RFC7321 to SHOULD.
> >
> > NEW:
> >
> >   In that sense 256 bit keys
> >status has been raised from MAY in RFC7321 to MUST.
> >
> > > * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not
> > referenced
> > > anywhere in the document.  Should it be added to Table 1 at the MUST
> > > level?
> >
> > No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and
> > AUTH_AES_256_GMAC algorithms. The reason those
> > AUTH_AES_{128,256}_GMAC algorithms are listed here is, that they used to
> > be SHOULD+, and are now downgraded to MAY.
> >
> > The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is
> > not mentioned in the section 4.
> >
> > Your text edits seemed to be fine.
> > --
> > kivi...@iki.fi
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] RFC4301, rfc7321bis and Manual keys

[Timothy Carlin]

Hello  All,

I have some comments inline.

On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters  wrote:

> On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote:
>
> OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is
>> OSPFv3 uses multicast.
>> So I could see manual key IPsec could be needed in any multicast
>> applications since group key management is not widely available
>> For above reason, I think it should be "MAY" instead of "SHOULD NOT"
>>
>
> Reading that RFC, it is really cracking on all sides. You even need to
> use the same SPIs and ENC keys for inbound and outbound SA's. I really
> don't think this is a very well thought out use case for IPsec.
>
> Are people actually deploying this?
>
>
The NIST USGv6 Profile current mandates RFC4552 and as such manual keys.


> How long are these static SPIs/keys used for? forever?
>
> I don't think we need to take those requirements into consideration. If
> anything, someone needs to update RFC4552 to allow for a more modern use
> of IKEv2 and multicast (RFC5374)
>
> The RFC4301 requires support for manual keys (section 4.5), but I hope
>>> nobody really uses them.
>>>
>>
> I have hoped that for many years. And like Transport Mode and IPCOMP,
> these things refuse to die. Anyways, we are not updating 4301, so I
> think this part is out of scope, but:
>
> The rfc7321bis provides mandatory to implement
>>> algorithms for the IKEv2 use, and does not really specifically cover
>>> manual keys
>>> cases, but it does not really say that manual keyed SAs are out of scope
>>> either
>>> (like it does say for IKEv1).
>>>
>>
> I guess 7321 should have had a note about manual keying in it, and it
> does not. We can surely add a note about manual keying.
>
> The issue is that some of the conformance logo documents actually do
>>> require
>>> manual keys, and to gain those logos implementors need to add support for
>>> manual keyed SAs even when nobody is really going to use them (i.e.,
>>> adding
>>> support for manual keys for android VPN client seems little stupid).
>>>
>>
> 7321bis should not change the requirement for manual keying. It should
> only talk about algorithms.
>
> On the other hand if you use the rfc7321bis requirements for also manual
>>> keys,
>>> there is only one suggested cipher that can be used, namely ENCR_AES_CBC.
>>>
>>> None of the counter mode ciphers are safe to use with manual keys, and
>>> for
>>> example RFC4106 (AES-GCM) requires using automated key management.
>>> The RFC4309 (AES-CCM) says that it "should not be used with statically
>>> configured keys", and that "MUST use fress keys". RFC7634
>>> (Chacha20-poly1305) does not explictly say anything about manual keys,
>>> but
>>> says it gets bitstring called KEYMAT from IKE...
>>>
>>> If we assume rfc7431bis can be used with manual keys too, we need to add
>>> some more text saying these ciphers cannot be used with manual keys.
>>>
>>
> Anyways, I think it should be time to mark manual keys as SHOULD NOT.
>>>
>>
> While I agree, I don't think 7321bis should do that.
>
> How about a new section between section 2 and 3:
>
> Manual Keying
>
> Manual Keying should not be used as it is inherently dangerous. Without
> any keying protocol, it does not offer Perfect Forward Secrecy
> protection. Deployments tend to never be reconfigured with fresh session
> keys. It also fails to scale and keeping SPI's unique amongst many servers
> is impractical. This document was written for deploying ESP/AH using IKE
> (RFC7298) and assumes that keying happens using IKEv2.
>
> If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
> ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT
> be used as these algorithms require IKE.
>
> [note the first "should not" is in lower case in purpose, so we don't
>  actually need to update 4301]
>
>
I agree with the sentiment that Manual Keys should be avoided.  However for
the conformance logo documents it would be helpful to have RFC2119 language
to point to when setting the requirements for testing.

Tim Carlin
UNH-IOL


> Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT
>>> be used, and mark it as updating RFC4301?
>>>
>>> Or should we have separate RFC stating that?
>>>
>>
> draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :)
>
> Seriously though, I don't think writing a document like that will change
> anything. And at least on Linux, the ip xfrm command allows for manual
> keying and therefor assist with testing, but the IKE daemons (libreswan,
> strongswan and openswan) do not support manual keying anymore.
>
> Paul
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Security Gateway PMTU Discovery

[Timothy Carlin]

Hello,

The UNH-IOL would like to ask the Working Group for feedback regarding an issue 
we've observed.

This issue concerns how a Security Gateway handles IPv6 MTU restrictions and 
fragmentations.  Specifically, how should a SGW handle a received Packet Too 
Big message, for an ESP packet which it transmitted?

From RFC 4301, Section 6.1.1, there are two options:

 If an ICMP PMTU message passes the checks above and the system is
 configured to accept it, then there are two possibilities.  If the
 implementation applies fragmentation on the ciphertext side of the
 boundary, then the accepted PMTU information is passed to the
 forwarding module (outside of the IPsec implementation), which uses
 it to manage outbound packet fragmentation.  If the implementation is
 configured to effect plaintext side fragmentation, then the PMTU
 information is passed to the plaintext side and processed as
 described in Section 8.2.

The first option, applying fragmentation on the ciphertext side of the boundary 
seems to be optional, although it's not clear to us if it only applies to IPv4, 
according to RFC 4303, Section 3.3.4:
 Thus, an ESP implementation MAY choose to not support fragmentation
 and may mark transmitted packets with the DF bit, to facilitate Path
 MTU (PMTU) discovery.

The second option is describe in RFC 4301, Section 8.2.1, which is to propagate 
the PMTU information via a synthesized Packet Too Big message.

So, there are two questions we would like to raise.

First, if ciphertext side fragmentation is indeed optional, and an IPv6 SGW 
implementation should choose to not support it, MUST it support generating the 
synthesized PTB message?

Second, the SGW can set the MTU to 1280 bytes, or less, in the synthesized 
Packet Too Big message, however, the originator is not required to reduce the 
size of fragments to less than 1280 bytes, but by adding the ESP header the 
resulting packets will be larger than 1280 bytes.  So, if the upstream MTU is 
1280 bytes, and an SGW implementation chooses to not to support ciphertext side 
fragmentation, what is the correct behavior?

Regards,
Timothy Carlin


Timothy Carlin
UNH-IOL
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2 Traffic Selectors

[Timothy Carlin]

Hi Tero,

Thank you for your comments.  This was along the same lines as what we 
suspected.

Regards,
Tim Carlin


On Feb 14, 2012, at 9:45 AM, Tero Kivinen wrote:

 Timothy Carlin writes:
 Hello,
 
 During testing, the UNH-IOL has encountered a behavior with regards
 to the handling of Traffic Selectors that causes interoperability
 issues.
 
 The issue center around the handling of this quote from RFC 5996,
 Section 2.9:
 
 “To enable the responder to choose the appropriate range in this case,
 if the initiator has requested the SA due to a data packet, the
 initiator SHOULD include as the first Traffic Selector in each of TSi
 and TSr a very specific Traffic Selector including the addresses in
 the packet triggering the request.”
 
 
 We've seen that implementations acting as the responder handle the
 Very Specific Traffic Selector in different ways, resulting in
 non-interoperability. Some implementations reject the connection,
 due to not matching configured selectors, while other
 implementations accept only this traffic selector, inadvertently
 narrowing the tunnel.
 
 Both of these types of implementation are not really following the
 spirit of the IKEv2 RFC.
 
 The ones who reject the connection, only support startup style SAs,
 and nothing else (which is allowed by IKEv2, but it is very limited
 implementation).
 
 The others which only accept only this traffic selectors, usually are
 limited to exactly one traffic selector, i.e. they do not support
 multiple traffic selectors (which again is allowed by IKEv2, but again
 is very limited implementation).
 
 I would myself consider both of them as broken IKEv2 implementations,
 and not to be used outside the very specific scenarios.
 
 Most of these are IKEv1 implementations hacked to support IKEv2 very
 quickly and in their hacking they didn't want to support multiple
 traffic selectors in the same SA, as that would change the IPsec
 packet engine also.
 
 This also causes a detrimental oddity when the data packet causing
 SA creation is an ICMPv6 Echo Request.  In this case, both TSi and
 TSr indicate ICMPv6, type 80, Code 00.  This is a special case,
 since ICMP has no source and destination port.  What should the
 proper behavior be for a packet type with no source and destination
 port?
 
 The RFC4301 section 4.4.1.3 has text about the ICMP port selectors,
 but that text really only covers the policy parts. When filling up the
 data from the packet information to the TS, this is not that much
 applicable, but on the other hand the first TS is also matched against
 the local policy, so they should be compatible.
 
 For the first TS matching the packet, I think best would be to use
 both src and dst port selectors as same value, i.e. copy the value
 to both fields.
 
 On the other hand reading 4.4.1.3 and matching the case C and D:
 
 --
C. If a system is willing to send traffic with a particular
   port value but NOT receive traffic with that kind of
   port value, the system's traffic selectors are set as
   follows in the relevant SPD entry:
 
   Local's
 next layer protocol = ICMP
 port selector = specific ICMP type  code
 
   Remote's
 next layer protocol = ICMP
 port selector = OPAQUE
 
D. To indicate that a system is willing to receive traffic
   with a particular port value but NOT send that kind of
   traffic, the system's traffic selectors are set as follows
   in the relevant SPD entry:
 
   Local's
 next layer protocol = ICMP
 port selector = OPAQUE
 
   Remote's
 next layer protocol = ICMP
 port selector = specific ICMP type  code
 
   For example, if a security gateway is willing to allow
   systems behind it to send ICMP traceroutes, but is not
   willing to let outside systems run ICMP traceroutes to
   systems behind it, then the security gateway's traffic
   selectors are set as follows in the relevant SPD entry:
 
   Local's
 next layer protocol = 1 (ICMPv4)
 port selector = 30 (traceroute)
 
   Remote's
 next layer protocol = 1 (ICMPv4)
 port selector = OPAQUE
 --
 
 (I.e. Local = incoming from the clear side, going to the SA, remote
 = incoming from SA, going to the clear side). 
 
 This would mean that if SGW has policy that allows clients to ping it
 but not anything behind the SGW to ping out that would be the case C,
 i.e. SGWs Local's policy part would say ICMP echo request and that
 would match the incoming TSr, and the SGWs Remote's policy part would
 say OPAQUE (i.e. TSi). For the normal narrowing rules to work this
 would require the initiator system to use:
 
 TSi

[IPsec] IPsec SGW PMTU

[Timothy Carlin]

Hello,

A question has come up regarding the interpretation of RFC 4301 and IPv6 Path 
MTU Discovery for Security Gateway Devices.  We would appreciate any insight 
anyone can offer.

Section 8.2.1 indicates that the SG should map the header information from the 
payload in a received (inbound) ICMPv6 Packet Too Big message to an SA.  Then, 
when another outbound packet is received that should be tunneled through that 
SA, it should drop the packet, and propagate the PMTU information through a 
synthesized PTB message.  This seems to be the only option for IPv6.

Section 6 states: The discussion in this section applies to ICMPv6 as well as 
to ICMPv4.

Section 6.1.1 gives two possibilities for processing, the second case refers to 
Section 8.2.1, while the first case states:  If the implementation applies 
fragmentation on the ciphertext side of the boundary, then the accepted PMTU 
information is passed to the forwarding module (outside of the IPsec 
implementation), which uses it to manage outbound packet fragmentation

The question is: Does this statement apply to both IPv4 and IPv6, or does it 
only apply to IPv4/ICMPv4?  Section 8.2.1 seems to imply that it would not 
apply to IPv6, meaning PTMU information should always be propagated in IPv6, 
however section 6 seems to state that it applies to both, and the 
implementation may choose to fragment.

Thanks for your time,

Tim Carlin


Timothy Carlin
InterOperability Laboratory
University of New Hampshire
+1-603-862-1224
tjcar...@iol.unh.edu
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec